cip-dev@lists.cip-project.org | [cip-security] [cip-dev] Python 3.x vs 2.7

masashi.kudo@cybertrust.co.jp <masashi.kudo@...>

#4567

Hi, 

The security WG nominated duplicity as a solution for "Control system backup" (CR7.3).
One of the common requirements of such backup software is check-point restart capability.
Duplicity provides this like the following.
https://lists.nongnu.org/archive/html/duplicity-announce/2009-06/msg00000.html

IMHO, I think tar is not met IEC63443-4-2 requirement, because tar itself does not have this capability,

Best regards,
--
M. Kudo

Show quoted text

-----Original Message-----
From: cip-security@... <cip-security@...> On Behalf Of Kento Yoshida
Sent: Tuesday, April 7, 2020 3:49 PM
To: Pavel Machek <pavel@...>; Jan Kiszka <jan.kiszka@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Hi,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Tuesday, April 7, 2020 6:52 AM
To: Jan Kiszka <jan.kiszka@...>
Cc: Pavel Machek <pavel@...>; Kento Yoshida 
<kento.yoshida.wz@...>; cip-security@...;
cip-dev@...
Subject: Re: [cip-dev] Python 3.x vs 2.7

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:
On 03.04.20 23:47, Pavel Machek wrote:
Hi!

FYI, unfortunately we couldn't find the alternative package forsystem backup. The duplicity is the best package for us from the 
license and num of dependencies point of view.

See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.htI'm not sure what your exact requirements are, but have youconsidered
"tar"? It should be possible to pipe its output to aespipe (and 
possibly other tools) to get encryption, and it should be able todo
incremental backups...I suppose there is that concern about GPLv3 again (as with broadlyused
rsync) - which is generally overrated. There exists legal views thatalready
GPLv2 requires to keep such licensed components replaceable on thetarget.
What then effectively remains with v3 is its, well, wordingcomplexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.
Some of the security members didn't accept GPLv3, so currently we dropped GPLv3 packages from the candidates.

BTW, I'm not sure but is the CIP policy on accepting GPLv3 still to be decided?

If that's out of question, I'm pretty sure we can get GPLv2 tar 
implementation somewhere. busybox has implementation, and I'm pretty 
sure there's GPLv2 fork of busybox. Old version of tar should be GPLv2. 
Still better than porting duplicity to different python version...
Thank you for introduction about "tar".
I will investigate whether it meets the requirements.
And also I'll search GPLv2 implementation if it meets the requirements.
If it's not decided yet about the CIP policy on accepting GPLv3, we cannot adopt GPLv3 packages.

Anyway, I agreed it is difficult to support python 2 for a super long term. And everyone agreed on this point.
So, we cannot support each libraries using python 2, at least.

Best regards, Kent

Best regards,
                                                               Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

Kento Yoshida

#4583

Hi,

I'll share you the functional requirements for system backup:

1. Regular periodic backup
2. Differential archives backup (to be light not to affect normal operation)
3. Encrypting/Decrypting the backup data
4. Return to checkpoint and restart

We selected the duplicity as the package that meet these requirement, and the duplicity had smaller dependencies compared to similar packages.

But we need to deeply consider the following point:

"How to handle packages with dependent packages such as python 2.7 that are not suitable for long-term maintenance, i.e. EOL."
Do we need to exclude that kind of package?
Or, do we backport from the upper version? by CIP? Or, funding? etc...

I'll submit to the list as the agenda of next CIP core meeting as an issue that requires a common policy, not just a duplicity issue.

Best regards, Kent

Show quoted text

-----Original Message-----
From: cip-dev@... <cip-dev@...> On Behalf Of
masashi.kudo@... via lists.cip-project.org
Sent: Wednesday, April 8, 2020 6:24 PM
To: cip-security@...; pavel@...; jan.kiszka@...
Cc: cip-dev@...
Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Hi,

The security WG nominated duplicity as a solution for "Control system backup"
(CR7.3).
One of the common requirements of such backup software is check-point restart
capability.
Duplicity provides this like the following.
https://lists.nongnu.org/archive/html/duplicity-announce/2009-06/msg00000.ht
ml

IMHO, I think tar is not met IEC63443-4-2 requirement, because tar itself does not
have this capability,

Best regards,
--
M. Kudo

-----Original Message-----
From: cip-security@... <cip-security@...> On
Behalf Of Kento Yoshida
Sent: Tuesday, April 7, 2020 3:49 PM
To: Pavel Machek <pavel@...>; Jan Kiszka <jan.kiszka@...>
Cc: cip-security@...; cip-dev@...
Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7

Hi,

-----Original Message-----
From: Pavel Machek <pavel@...>
Sent: Tuesday, April 7, 2020 6:52 AM
To: Jan Kiszka <jan.kiszka@...>
Cc: Pavel Machek <pavel@...>; Kento Yoshida
<kento.yoshida.wz@...>; cip-security@...;
cip-dev@...
Subject: Re: [cip-dev] Python 3.x vs 2.7

On Mon 2020-04-06 12:15:16, Jan Kiszka wrote:
On 03.04.20 23:47, Pavel Machek wrote:
Hi!

FYI, unfortunately we couldn't find the alternative package forsystem backup. The duplicity is the best package for us from the
license and num of dependencies point of view.

See the following.
<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.htI'm not sure what your exact requirements are, but have youconsidered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able todo
incremental backups...I suppose there is that concern about GPLv3 again (as with broadlyused
rsync) - which is generally overrated. There exists legal views thatalready
GPLv2 requires to keep such licensed components replaceable on thetarget.
What then effectively remains with v3 is its, well, wordingcomplexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.
Some of the security members didn't accept GPLv3, so currently we dropped
GPLv3 packages from the candidates.

BTW, I'm not sure but is the CIP policy on accepting GPLv3 still to be decided?

If that's out of question, I'm pretty sure we can get GPLv2 tar
implementation somewhere. busybox has implementation, and I'm pretty
sure there's GPLv2 fork of busybox. Old version of tar should be GPLv2.
Still better than porting duplicity to different python version...
Thank you for introduction about "tar".
I will investigate whether it meets the requirements.
And also I'll search GPLv2 implementation if it meets the requirements.
If it's not decided yet about the CIP policy on accepting GPLv3, we cannot adopt
GPLv3 packages.

Anyway, I agreed it is difficult to support python 2 for a super long term. And
everyone agreed on this point.
So, we cannot support each libraries using python 2, at least.

Best regards, Kent

Best regards,
                                                               Pavel
--
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany