[cip-dev] Python 3.x vs 2.7

[cip-dev] Python 3.x vs 2.7

[Kento Yoshida]

[-- Attachment #1.1: Type: text/plain, Size: 2062 bytes --]

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

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

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV
Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent

[-- Attachment #1.2: Type: text/html, Size: 15126 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[nobuhiro1.iwamatsu]

Hi, 

> As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:
>
> 1. Maintain python 2.7 as well
> 2. Backport the upper duplicity which migrated python 3.x in bullseye archive
> 3. Others
>
> What do you think is best?
> I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

In my opinion, it is difficult to support Python2 for a super long term. And I think it is difficult to support each library using Python2.
Therefore, I think Option2 is good. And if necessary, we can use backposts.debian.org.
However, packages with large dependencies can be difficult to backports. For example Kbuckup is difficult, I think.

Best regards,
  Nobuhiro

From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento Yoshida
Sent: Thursday, April 2, 2020 6:59 PM
To: cip-dev@lists.cip-project.org
Cc: cip-security@lists.cip-project.org
Subject: [cip-dev] Python 3.x vs 2.7

Hi CIP core group,

The security package proposal is suspended now, but I'd like to discuss about the python version which is suitable to maintain.

We selected "duplicity" for the requirement of system backup according to the functionality, license, the number of dependencies and so on.
However, the duplicity in the Debian buster [1] dependent on python 2.7, which is not maintained anymore [2].

[1] https://packages.debian.org/source/buster/duplicity
[2] https://pythonclock.org/

As you may know, some of other packages we selected are dependent on python 3.x, so we may have the below options:

1. Maintain python 2.7 as well
2. Backport the upper duplicity which migrated python 3.x in bullseye archive
3. Others

What do you think is best?
I hope we can decide the policy within the CIP core group because there shall be similar problems for the others of python.

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

<Rsync>
Encryption: No
Schedule backup: No
Incremental backup: Yes
License: GPL v3
Dependencies count (aprox): 24
Reference: https://rsync.samba.org/features.html

<duplicity>
Encryption: Yes
Schedule backup: No
Incremental backup: Yes
License: GPL v2
Dependencies count (aprox): 80
Reference: http://duplicity.nongnu.org/features.ht

<Backuppc>
Encryption: No
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+, X11
Dependencies count (aprox): 132
Reference: http://backuppc.sourceforge.net/info.html

<Amanda>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2+
Dependencies count (aprox): 289
Reference: https://www.zmanda.com/amanda-community-edition.html

<Kbackup>
Encryption: Yes
Schedule backup: Yes
Incremental backup: Yes
License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV
Dependencies count (aprox): 414
Reference: https://kde.org/applications/utilities/org.kde.kbackup

Best regards,
Kent
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[Kento Yoshida]

Thank you for your feedback, Iwamatsu-san.

>-----Original Message-----
>From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>
>Sent: Friday, April 3, 2020 8:19 AM
>To: Kento Yoshida <kento.yoshida.wz@renesas.com>; cip-dev@lists.cip-project.org
>Cc: cip-security@lists.cip-project.org
>Subject: RE: Python 3.x vs 2.7
>
>Hi,
>
>> As you may know, some of other packages we selected are dependent on python
>3.x, so we may have the below options:
>>
>> 1. Maintain python 2.7 as well
>> 2. Backport the upper duplicity which migrated python 3.x in bullseye
>> archive 3. Others
>>
>> What do you think is best?
>> I hope we can decide the policy within the CIP core group because there shall be
>similar problems for the others of python.
>
>In my opinion, it is difficult to support Python2 for a super long term. And I think
>it is difficult to support each library using Python2.
>Therefore, I think Option2 is good. And if necessary, we can use
>backposts.debian.org.

Actually, option-2 is dominant in the security team as well.

>However, packages with large dependencies can be difficult to backports. For
>example Kbuckup is difficult, I think.
>

Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.

>Best regards,
>  Nobuhiro
>
>From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
>Yoshida
>Sent: Thursday, April 2, 2020 6:59 PM
>To: cip-dev@lists.cip-project.org
>Cc: cip-security@lists.cip-project.org
>Subject: [cip-dev] Python 3.x vs 2.7
>
>Hi CIP core group,
>
>The security package proposal is suspended now, but I'd like to discuss about the
>python version which is suitable to maintain.
>
>We selected "duplicity" for the requirement of system backup according to the
>functionality, license, the number of dependencies and so on.
>However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
>not maintained anymore [2].
>
>[1] https://packages.debian.org/source/buster/duplicity
>[2] https://pythonclock.org/
>
>As you may know, some of other packages we selected are dependent on python
>3.x, so we may have the below options:
>
>1. Maintain python 2.7 as well
>2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
>Others
>
>What do you think is best?
>I hope we can decide the policy within the CIP core group because there shall be
>similar problems for the others of python.
>
>FYI, unfortunately we couldn't find the alternative package for system backup. The
>duplicity is the best package for us from the license and num of dependencies
>point of view.
>See the following.
>
><Rsync>
>Encryption: No
>Schedule backup: No
>Incremental backup: Yes
>License: GPL v3
>Dependencies count (aprox): 24
>Reference: https://rsync.samba.org/features.html
>
><duplicity>
>Encryption: Yes
>Schedule backup: No
>Incremental backup: Yes
>License: GPL v2
>Dependencies count (aprox): 80
>Reference: http://duplicity.nongnu.org/features.ht
>
><Backuppc>
>Encryption: No
>Schedule backup: Yes
>Incremental backup: Yes
>License: GPL-2+, X11
>Dependencies count (aprox): 132
>Reference: http://backuppc.sourceforge.net/info.html
>
><Amanda>
>Encryption: Yes
>Schedule backup: Yes
>Incremental backup: Yes
>License: GPL-2+
>Dependencies count (aprox): 289
>Reference: https://www.zmanda.com/amanda-community-edition.html
>
><Kbackup>
>Encryption: Yes
>Schedule backup: Yes
>Incremental backup: Yes
>License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
>Reference: https://kde.org/applications/utilities/org.kde.kbackup
>
>Best regards,
>Kent
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[Pavel Machek]

[-- Attachment #1.1: Type: text/plain, Size: 830 bytes --]

Hi!

> 
> FYI, unfortunately we couldn't find the alternative package for system 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.ht

I'm not sure what your exact requirements are, but have you considered
"tar"? It should be possible to pipe its output to aespipe (and
possibly other tools) to get encryption, and it should be able to do
incremental backups...

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 154 bytes --]

_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[Punit Agrawal]

Hi Kent,

Kento Yoshida <kento.yoshida.wz@renesas.com> writes:

> Thank you for your feedback, Iwamatsu-san.
>
>>-----Original Message-----
>>From: nobuhiro1.iwamatsu@toshiba.co.jp <nobuhiro1.iwamatsu@toshiba.co.jp>

[...]

>>> As you may know, some of other packages we selected are dependent on python
>>3.x, so we may have the below options:
>>>
>>> 1. Maintain python 2.7 as well
>>> 2. Backport the upper duplicity which migrated python 3.x in bullseye
>>> archive 3. Others
>>>
>>> What do you think is best?
>>> I hope we can decide the policy within the CIP core group because there shall be
>>similar problems for the others of python.
>>
>>In my opinion, it is difficult to support Python2 for a super long term. And I think
>>it is difficult to support each library using Python2.
>>Therefore, I think Option2 is good. And if necessary, we can use
>>backposts.debian.org.
>
> Actually, option-2 is dominant in the security team as well.

From a brief look at the pros / cons between the two choices (below), I
am also biased towards backporting a python3 based version of duplicity.

Suggested next steps further down - 

* Python2

  Pros
  ----
  * No backport (to Buster) needed (least effort, right now)

  Cons
  ----
  * Has reached EOL in upstream. Not sure about ELTS support. It maybe
  that if we go with Python2, we (CIP) is on our own.


* Python3

  Pros
  ----
  * Python3 is available in Debian Buster
  * Likely to be supported for longer time - upstream and in Debian

  Cons
  ----
  * Needs backporting duplicity (and dependencies) to Buster via
    backports to align with upstream first approach of CIP.
    - From a quick check of dependencies in bullseye a backport of
      librsync2 might also be needed.


Next steps
----------
* Investigate the effort to backport duplicity (and dependencies) to
  buster-backports.
* If no major surprises are found during the investigation, work with
  Debian upstream to upload the new version.

Hope that makes sense.

Thanks,
Punit


>>However, packages with large dependencies can be difficult to backports. For
>>example Kbuckup is difficult, I think.
>>
>
> Agree. We are not going to select the package which is GPL-3 or has a lot of dependent package, so the duplicity is only one candidate for us substantially.
>
>>Best regards,
>>  Nobuhiro
>>
>>From: cip-dev [mailto:cip-dev-bounces@lists.cip-project.org] On Behalf Of Kento
>>Yoshida
>>Sent: Thursday, April 2, 2020 6:59 PM
>>To: cip-dev@lists.cip-project.org
>>Cc: cip-security@lists.cip-project.org
>>Subject: [cip-dev] Python 3.x vs 2.7
>>
>>Hi CIP core group,
>>
>>The security package proposal is suspended now, but I'd like to discuss about the
>>python version which is suitable to maintain.
>>
>>We selected "duplicity" for the requirement of system backup according to the
>>functionality, license, the number of dependencies and so on.
>>However, the duplicity in the Debian buster [1] dependent on python 2.7, which is
>>not maintained anymore [2].
>>
>>[1] https://packages.debian.org/source/buster/duplicity
>>[2] https://pythonclock.org/
>>
>>As you may know, some of other packages we selected are dependent on python
>>3.x, so we may have the below options:
>>
>>1. Maintain python 2.7 as well
>>2. Backport the upper duplicity which migrated python 3.x in bullseye archive 3.
>>Others
>>
>>What do you think is best?
>>I hope we can decide the policy within the CIP core group because there shall be
>>similar problems for the others of python.
>>
>>FYI, unfortunately we couldn't find the alternative package for system backup. The
>>duplicity is the best package for us from the license and num of dependencies
>>point of view.
>>See the following.
>>
>><Rsync>
>>Encryption: No
>>Schedule backup: No
>>Incremental backup: Yes
>>License: GPL v3
>>Dependencies count (aprox): 24
>>Reference: https://rsync.samba.org/features.html
>>
>><duplicity>
>>Encryption: Yes
>>Schedule backup: No
>>Incremental backup: Yes
>>License: GPL v2
>>Dependencies count (aprox): 80
>>Reference: http://duplicity.nongnu.org/features.ht
>>
>><Backuppc>
>>Encryption: No
>>Schedule backup: Yes
>>Incremental backup: Yes
>>License: GPL-2+, X11
>>Dependencies count (aprox): 132
>>Reference: http://backuppc.sourceforge.net/info.html
>>
>><Amanda>
>>Encryption: Yes
>>Schedule backup: Yes
>>Incremental backup: Yes
>>License: GPL-2+
>>Dependencies count (aprox): 289
>>Reference: https://www.zmanda.com/amanda-community-edition.html
>>
>><Kbackup>
>>Encryption: Yes
>>Schedule backup: Yes
>>Incremental backup: Yes
>>License: GPL-2, LGPL-2.1, GFDL-1.2+, KDEeV Dependencies count (aprox): 414
>>Reference: https://kde.org/applications/utilities/org.kde.kbackup
>>
>>Best regards,
>>Kent
> _______________________________________________
> cip-dev mailing list
> cip-dev@lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[Jan Kiszka]

On 03.04.20 23:47, Pavel Machek wrote:
> Hi!
> 
>>
>> FYI, unfortunately we couldn't find the alternative package for system 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.ht
> 
> I'm not sure what your exact requirements are, but have you considered
> "tar"? It should be possible to pipe its output to aespipe (and
> possibly other tools) to get encryption, and it should be able to do
> incremental backups...

I suppose there is that concern about GPLv3 again (as with broadly used 
rsync) - which is generally overrated. There exists legal views that 
already GPLv2 requires to keep such licensed components replaceable on 
the target. What then effectively remains with v3 is its, well, wording 
complexity.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev

Re: [cip-dev] Python 3.x vs 2.7

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 2096 bytes --]

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 for system 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.ht
> > 
> > I'm not sure what your exact requirements are, but have you considered
> > "tar"? It should be possible to pipe its output to aespipe (and
> > possibly other tools) to get encryption, and it should be able to do
> > incremental backups...
> 
> I suppose there is that concern about GPLv3 again (as with broadly used
> rsync) - which is generally overrated. There exists legal views that already
> GPLv2 requires to keep such licensed components replaceable on the target.
> What then effectively remains with v3 is its, well, wording complexity.

Does "tar" match the requirements?

And I agree that best option would be to accept GPLv3.

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...

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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4555): https://lists.cip-project.org/g/cip-dev/message/4555
Mute This Topic: https://lists.cip-project.org/mt/72826088/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [cip-dev] Python 3.x vs 2.7

[Kento Yoshida]

[-- Attachment #1: Type: text/plain, Size: 3225 bytes --]

Hi,

>-----Original Message-----
>From: Pavel Machek <pavel@denx.de>
>Sent: Tuesday, April 7, 2020 6:52 AM
>To: Jan Kiszka <jan.kiszka@siemens.com>
>Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida
><kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
>cip-dev@lists.cip-project.org
>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 for
>system 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.ht
>> >
>> > I'm not sure what your exact requirements are, but have you
>considered
>> > "tar"? It should be possible to pipe its output to aespipe (and
>> > possibly other tools) to get encryption, and it should be able to
>do
>> > incremental backups...
>>
>> I suppose there is that concern about GPLv3 again (as with broadly
>used
>> rsync) - which is generally overrated. There exists legal views that
>already
>> GPLv2 requires to keep such licensed components replaceable on the
>target.
>> What then effectively remains with v3 is its, well, wording
>complexity.
>
>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

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4558): https://lists.cip-project.org/g/cip-dev/message/4558
Mute This Topic: https://lists.cip-project.org/mt/72826088/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-


[-- Attachment #2: openpgp-digital-signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

Re: [cip-security] [cip-dev] Python 3.x vs 2.7

[masashi.kudo]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

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

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

Hi,

>-----Original Message-----
>From: Pavel Machek <pavel@denx.de>
>Sent: Tuesday, April 7, 2020 6:52 AM
>To: Jan Kiszka <jan.kiszka@siemens.com>
>Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida 
><kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
>cip-dev@lists.cip-project.org
>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 for
>system 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.ht
>> >
>> > I'm not sure what your exact requirements are, but have you
>considered
>> > "tar"? It should be possible to pipe its output to aespipe (and 
>> > possibly other tools) to get encryption, and it should be able to
>do
>> > incremental backups...
>>
>> I suppose there is that concern about GPLv3 again (as with broadly
>used
>> rsync) - which is generally overrated. There exists legal views that
>already
>> GPLv2 requires to keep such licensed components replaceable on the
>target.
>> What then effectively remains with v3 is its, well, wording
>complexity.
>
>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




[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4567): https://lists.cip-project.org/g/cip-dev/message/4567
Mute This Topic: https://lists.cip-project.org/mt/72870644/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-security] [cip-dev] Python 3.x vs 2.7

[Kento Yoshida]

[-- Attachment #1: Type: text/plain, Size: 5002 bytes --]

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

>-----Original Message-----
>From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of
>masashi.kudo@cybertrust.co.jp via lists.cip-project.org
>Sent: Wednesday, April 8, 2020 6:24 PM
>To: cip-security@lists.cip-project.org; pavel@denx.de; jan.kiszka@siemens.com
>Cc: cip-dev@lists.cip-project.org
>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@lists.cip-project.org <cip-security@lists.cip-project.org> On
>Behalf Of Kento Yoshida
>Sent: Tuesday, April 7, 2020 3:49 PM
>To: Pavel Machek <pavel@denx.de>; Jan Kiszka <jan.kiszka@siemens.com>
>Cc: cip-security@lists.cip-project.org; cip-dev@lists.cip-project.org
>Subject: Re: [cip-security] [cip-dev] Python 3.x vs 2.7
>
>Hi,
>
>>-----Original Message-----
>>From: Pavel Machek <pavel@denx.de>
>>Sent: Tuesday, April 7, 2020 6:52 AM
>>To: Jan Kiszka <jan.kiszka@siemens.com>
>>Cc: Pavel Machek <pavel@denx.de>; Kento Yoshida
>><kento.yoshida.wz@renesas.com>; cip-security@lists.cip-project.org;
>>cip-dev@lists.cip-project.org
>>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 for
>>system 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.ht
>>> >
>>> > I'm not sure what your exact requirements are, but have you
>>considered
>>> > "tar"? It should be possible to pipe its output to aespipe (and
>>> > possibly other tools) to get encryption, and it should be able to
>>do
>>> > incremental backups...
>>>
>>> I suppose there is that concern about GPLv3 again (as with broadly
>>used
>>> rsync) - which is generally overrated. There exists legal views that
>>already
>>> GPLv2 requires to keep such licensed components replaceable on the
>>target.
>>> What then effectively remains with v3 is its, well, wording
>>complexity.
>>
>>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
>
>


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4583): https://lists.cip-project.org/g/cip-dev/message/4583
Mute This Topic: https://lists.cip-project.org/mt/72870644/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-