[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[kazuhiro3.hayashi at toshiba.co.jp]

Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews, please let me know if any requests)

Best regards,
Kazu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_20191209.yml
Type: application/octet-stream
Size: 10095 bytes
Desc: proposal_20191209.yml
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20191209/c2c81252/attachment.obj>

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[Kento Yoshida]

Hello Kazu and CIP Core working group members,

>From Renesas, agree with this proposal.

Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of kazuhiro3.hayashi at toshiba.co.jp
Sent: Monday, December 9, 2019 10:55 PM
To: cip-dev at lists.cip-project.org
Subject: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Hello CIP Core members,

I would like to start the "review" phase (Phase 2) of the attached package proposal.
https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review

The packages are proposed by CIP security WG to satisfy their required features.
See the "reason" fields in the proposal for more details.

Please reply with you opinion, agree or disagree.
If you cannot agree to add specific packages, please show the reasons as well.

Due Date: December 23rd
(We can extend this due date if more time required for reviews, please let me know if any requests)

Best regards,
Kazu

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[Jan Kiszka]

On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
> Hello CIP Core members,
> 
> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pdp.md#phase-2-proposal-review
> 
> The packages are proposed by CIP security WG to satisfy their required features.
> See the "reason" fields in the proposal for more details.
> 
> Please reply with you opinion, agree or disagree.
> If you cannot agree to add specific packages, please show the reasons as well.
> 
> Due Date: December 23rd
> (We can extend this due date if more time required for reviews, please let me know if any requests)
> 

[...]

>   chrony:
>     bin_pkgs:
>       chrony:
>         depends:
>         - init-system-helpers
>         - adduser
>         - iproute2
>         - lsb-base
>         - ucf
>         - libc6
>         - libcap2
>         - libedit2
>         - libnettle6
>         - libseccomp2
>     in_target: 'True'
>     n_cve: '10'
>     reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
>     security_criteria: network::server, network::service

Why still chrony, why not simply systemd timers? Legacy?

>   suricata:
>     bin_pkgs:
>       suricata:
>         depends:
>         - dpkg
>         - python
>         - python-simplejson

I'm missing the new dependencies in the top-list. Didn't
we agree on listing them flat? This, e.g., pulls python, currently even  
v2 - anything but a trivial package. Or did I miss that we have this in  
our list already?

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[Kento Yoshida]

Thank you for your feedback, Jan.

> Why still chrony, why not simply systemd timers? Legacy?

We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized by CII as being a superior secure NTP implementation.
https://www.coreinfrastructure.org/blogs/securing-network-time/

Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony" would be more secure and sustainable.

>>   suricata:
>>     bin_pkgs:
>>       suricata:
>>         depends:
>>         - dpkg
>>         - python
>>         - python-simplejson
>
> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? 
> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in our list already?

@kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
Do you need a script modification to address this issue?
Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation in the security working group.
The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.

Best regards,
Kent
-----Original Message-----
From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
> Hello CIP Core members,
> 
> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> p.md#phase-2-proposal-review
> 
> The packages are proposed by CIP security WG to satisfy their required features.
> See the "reason" fields in the proposal for more details.
> 
> Please reply with you opinion, agree or disagree.
> If you cannot agree to add specific packages, please show the reasons as well.
> 
> Due Date: December 23rd
> (We can extend this due date if more time required for reviews, please 
> let me know if any requests)
> 

[...]

>   chrony:
>     bin_pkgs:
>       chrony:
>         depends:
>         - init-system-helpers
>         - adduser
>         - iproute2
>         - lsb-base
>         - ucf
>         - libc6
>         - libcap2
>         - libedit2
>         - libnettle6
>         - libseccomp2
>     in_target: 'True'
>     n_cve: '10'
>     reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
>     security_criteria: network::server, network::service

Why still chrony, why not simply systemd timers? Legacy?

>   suricata:
>     bin_pkgs:
>       suricata:
>         depends:
>         - dpkg
>         - python
>         - python-simplejson

I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python, currently even
v2 - anything but a trivial package. Or did I miss that we have this in our list already?

Jan

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

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[daniel.sangorrin at toshiba.co.jp]

> From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Kento Yoshida
> Thank you for your feedback, Jan.
> 
> > Why still chrony, why not simply systemd timers? Legacy?
> 
> We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is
> recognized by CII as being a superior secure NTP implementation.
> https://www.coreinfrastructure.org/blogs/securing-network-time/
> 
> Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony" would
> be more secure and sustainable.

Yoshida-san:
I agree with you that systemd-timesyncd is sufficient for most cases but chrony is superior and has more features including symmetric key authentication or reliability to intermittent connections..

Everyone:
There are two "suggested" dependencies that you weren't included.
- sug: dnsutils
Clientes proporcionados con BIND
- sug: networkd-dispatcher
Dispatcher service for systemd-networkd connection status changes

Perhaps it would be good to provide a reason for excluding or including those. Is this specified in the guide to add a new package?

Everyones:
There are dependencies such as "libseccomp2" or "iproute2" that may affect how the kernel should be configured. Should we also include that information somewhere?

Thanks,
Daniel


> 
> >>   suricata:
> >>     bin_pkgs:
> >>       suricata:
> >>         depends:
> >>         - dpkg
> >>         - python
> >>         - python-simplejson
> >
> > I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> > This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in our
> list already?
> 
> @kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
> Do you need a script modification to address this issue?
> Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
> in the security working group.
> The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
> 
> Best regards,
> Kent
> -----Original Message-----
> From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
> Sent: Thursday, December 19, 2019 7:48 PM
> To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> 
> On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
> > Hello CIP Core members,
> >
> > I would like to start the "review" phase (Phase 2) of the attached package proposal.
> > https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> > p.md#phase-2-proposal-review
> >
> > The packages are proposed by CIP security WG to satisfy their required features.
> > See the "reason" fields in the proposal for more details.
> >
> > Please reply with you opinion, agree or disagree.
> > If you cannot agree to add specific packages, please show the reasons as well.
> >
> > Due Date: December 23rd
> > (We can extend this due date if more time required for reviews, please
> > let me know if any requests)
> >
> 
> [...]
> 
> >   chrony:
> >     bin_pkgs:
> >       chrony:
> >         depends:
> >         - init-system-helpers
> >         - adduser
> >         - iproute2
> >         - lsb-base
> >         - ucf
> >         - libc6
> >         - libcap2
> >         - libedit2
> >         - libnettle6
> >         - libseccomp2
> >     in_target: 'True'
> >     n_cve: '10'
> >     reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >     security_criteria: network::server, network::service
> 
> Why still chrony, why not simply systemd timers? Legacy?
> 
> >   suricata:
> >     bin_pkgs:
> >       suricata:
> >         depends:
> >         - dpkg
> >         - python
> >         - python-simplejson
> 
> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> currently even
> v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> 
> Jan
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
> _______________________________________________
> cip-dev mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[Jan Kiszka]

On 20.12.19 03:25, Kento Yoshida wrote:
> Thank you for your feedback, Jan.
> 
>> Why still chrony, why not simply systemd timers? Legacy?
> 
> We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized by CII as being a superior secure NTP implementation.
> https://www.coreinfrastructure.org/blogs/securing-network-time/
> 
> Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony" would be more secure and sustainable.
> 

Oops, I actually confused cron and chrony here. Interestingly, the 
question "can't systemd do that?" remained valid :).

I agree to pick the more mature solution for this purpose.

>>>    suricata:
>>>      bin_pkgs:
>>>        suricata:
>>>          depends:
>>>          - dpkg
>>>          - python
>>>          - python-simplejson
>>
>> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
>> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> 
> @kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
> Do you need a script modification to address this issue?
> Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation in the security working group.
> The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.

We can only decide about package sets which have their runtime 
dependencies already fulfilled with the existing package set (where is 
that now, BTW?) or include these dependencies in the set. I only checked 
suricata because of the outstanding python dependency, but there might 
be more issue. This needs to be checked carefully again.

Jan

> 
> Best regards,
> Kent
> -----Original Message-----
> From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
> Sent: Thursday, December 19, 2019 7:48 PM
> To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
> Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> 
> On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
>> Hello CIP Core members,
>>
>> I would like to start the "review" phase (Phase 2) of the attached package proposal.
>> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
>> p.md#phase-2-proposal-review
>>
>> The packages are proposed by CIP security WG to satisfy their required features.
>> See the "reason" fields in the proposal for more details.
>>
>> Please reply with you opinion, agree or disagree.
>> If you cannot agree to add specific packages, please show the reasons as well.
>>
>> Due Date: December 23rd
>> (We can extend this due date if more time required for reviews, please
>> let me know if any requests)
>>
> 
> [...]
> 
>>    chrony:
>>      bin_pkgs:
>>        chrony:
>>          depends:
>>          - init-system-helpers
>>          - adduser
>>          - iproute2
>>          - lsb-base
>>          - ucf
>>          - libc6
>>          - libcap2
>>          - libedit2
>>          - libnettle6
>>          - libseccomp2
>>      in_target: 'True'
>>      n_cve: '10'
>>      reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
>>      security_criteria: network::server, network::service
> 
> Why still chrony, why not simply systemd timers? Legacy?
> 
>>    suricata:
>>      bin_pkgs:
>>        suricata:
>>          depends:
>>          - dpkg
>>          - python
>>          - python-simplejson
> 
> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python, currently even
> v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> 
> Jan
> 


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[kazuhiro3.hayashi at toshiba.co.jp]

Hello,

> On 20.12.19 03:25, Kento Yoshida wrote:
> > Thank you for your feedback, Jan.
> >
> >> Why still chrony, why not simply systemd timers? Legacy?
> >
> > We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> > The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized
> by CII as being a superior secure NTP implementation.
> > https://www.coreinfrastructure.org/blogs/securing-network-time/
> >
> > Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony"
> would be more secure and sustainable.
> >
> 
> Oops, I actually confused cron and chrony here. Interestingly, the
> question "can't systemd do that?" remained valid :).
> 
> I agree to pick the more mature solution for this purpose.
> 
> >>>    suricata:
> >>>      bin_pkgs:
> >>>        suricata:
> >>>          depends:
> >>>          - dpkg
> >>>          - python
> >>>          - python-simplejson
> >>
> >> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> >> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in
> our list already?
> >
> > @kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
> > Do you need a script modification to address this issue?

We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

> > Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
> in the security working group.
> > The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
> 
> We can only decide about package sets which have their runtime
> dependencies already fulfilled with the existing package set (where is
> that now, BTW?) or include these dependencies in the set. 

I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
   from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
   (e.g. If following this, the security package proposal pulls around 90 packages finally)

> I only checked
> suricata because of the outstanding python dependency, but there might
> be more issue. This needs to be checked carefully again.

Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members become clear.

Kazu

> 
> Jan
> 
> >
> > Best regards,
> > Kent
> > -----Original Message-----
> > From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
> > Sent: Thursday, December 19, 2019 7:48 PM
> > To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
> > Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >
> > On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
> >> Hello CIP Core members,
> >>
> >> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> >> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> >> p.md#phase-2-proposal-review
> >>
> >> The packages are proposed by CIP security WG to satisfy their required features.
> >> See the "reason" fields in the proposal for more details.
> >>
> >> Please reply with you opinion, agree or disagree.
> >> If you cannot agree to add specific packages, please show the reasons as well.
> >>
> >> Due Date: December 23rd
> >> (We can extend this due date if more time required for reviews, please
> >> let me know if any requests)
> >>
> >
> > [...]
> >
> >>    chrony:
> >>      bin_pkgs:
> >>        chrony:
> >>          depends:
> >>          - init-system-helpers
> >>          - adduser
> >>          - iproute2
> >>          - lsb-base
> >>          - ucf
> >>          - libc6
> >>          - libcap2
> >>          - libedit2
> >>          - libnettle6
> >>          - libseccomp2
> >>      in_target: 'True'
> >>      n_cve: '10'
> >>      reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >>      security_criteria: network::server, network::service
> >
> > Why still chrony, why not simply systemd timers? Legacy?
> >
> >>    suricata:
> >>      bin_pkgs:
> >>        suricata:
> >>          depends:
> >>          - dpkg
> >>          - python
> >>          - python-simplejson
> >
> > I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> currently even
> > v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> >
> > Jan
> >
> 
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[Jan Kiszka]

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi at toshiba.co.jp wrote:
>>>>>     suricata:
>>>>>       bin_pkgs:
>>>>>         suricata:
>>>>>           depends:
>>>>>           - dpkg
>>>>>           - python
>>>>>           - python-simplejson
>>>>
>>>> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
>>>> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in
>> our list already?
>>>
>>> @kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
>>> Do you need a script modification to address this issue?
> 
> We need to reconsider the format of proposal.yml (and scripts as well).
> It seems not to be reviewed enough.
> 
>>> Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
>> in the security working group.
>>> The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
>>
>> We can only decide about package sets which have their runtime
>> dependencies already fulfilled with the existing package set (where is
>> that now, BTW?) or include these dependencies in the set.
> 
> I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
> If so, there is no such list because this is the first proposal.

Then let's define that base (minimal debootstrap) first before adding 
further packages.

> 
> Also, it's difficult for me to agree with the opinion that
> "all runtime dependencies must be fullfilled with the existing package set" because
> 1) Some dependency (binary) packages are not functionally necessary
>     from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)

Anything that a Debian package requires needs to be present - otherwise 
the package becomes broken. I can't imagine we want to propose that to 
our users. Weaker dependencies are obviously optional.

If we should run into a package that seems to require more than it 
should, let's improve it by proposing a break-up upstream. Or by 
repackaging it in meta-debian / isar-cip-core. But that should come 
first before proposing it here.

> 2) The list including all dependencies may become big for CIP's "OSBL"
>     (e.g. If following this, the security package proposal pulls around 90 packages finally)

Anything in that range still seems reasonable from a maintenance 
perspective - provided there are no "challenging" packages included. But 
we should still check if that number is seriously needed, though.

Jan

> 
>> I only checked
>> suricata because of the outstanding python dependency, but there might
>> be more issue. This needs to be checked carefully again.
> 
> Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
> I will prepare this and will share in the next week.
> 
> So, please suspend this proposal process until requirements of all members become clear.
> 
> Kazu
> 
>>
>> Jan
>>
>>>
>>> Best regards,
>>> Kent
>>> -----Original Message-----
>>> From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
>>> Sent: Thursday, December 19, 2019 7:48 PM
>>> To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
>>> Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
>>>
>>> On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
>>>> Hello CIP Core members,
>>>>
>>>> I would like to start the "review" phase (Phase 2) of the attached package proposal.
>>>> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
>>>> p.md#phase-2-proposal-review
>>>>
>>>> The packages are proposed by CIP security WG to satisfy their required features.
>>>> See the "reason" fields in the proposal for more details.
>>>>
>>>> Please reply with you opinion, agree or disagree.
>>>> If you cannot agree to add specific packages, please show the reasons as well.
>>>>
>>>> Due Date: December 23rd
>>>> (We can extend this due date if more time required for reviews, please
>>>> let me know if any requests)
>>>>
>>>
>>> [...]
>>>
>>>>     chrony:
>>>>       bin_pkgs:
>>>>         chrony:
>>>>           depends:
>>>>           - init-system-helpers
>>>>           - adduser
>>>>           - iproute2
>>>>           - lsb-base
>>>>           - ucf
>>>>           - libc6
>>>>           - libcap2
>>>>           - libedit2
>>>>           - libnettle6
>>>>           - libseccomp2
>>>>       in_target: 'True'
>>>>       n_cve: '10'
>>>>       reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
>>>>       security_criteria: network::server, network::service
>>>
>>> Why still chrony, why not simply systemd timers? Legacy?
>>>
>>>>     suricata:
>>>>       bin_pkgs:
>>>>         suricata:
>>>>           depends:
>>>>           - dpkg
>>>>           - python
>>>>           - python-simplejson
>>>
>>> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
>> currently even
>>> v2 - anything but a trivial package. Or did I miss that we have this in our list already?
>>>
>>> Jan
>>>
>>
>>
>> --
>> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
>> Corporate Competence Center Embedded Linux


-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[masashi.kudo at cybertrust.co.jp]

Kazu-san,

Thanks for working on this.

  > Due Date: December 23rd
Originally, the due date was today.

> So, please suspend this proposal process until requirements of all members become clear.
Does this means that the above due date is extended and the new due date will be announced later?
Just to make sure.

Best regards,
--
M. Kudo


2019?12?20?(?) 18:59 <kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>>:
Hello,

> On 20.12.19 03:25, Kento Yoshida wrote:
> > Thank you for your feedback, Jan.
> >
> >> Why still chrony, why not simply systemd timers? Legacy?
> >
> > We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> > The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized
> by CII as being a superior secure NTP implementation.
> > https://www.coreinfrastructure.org/blogs/securing-network-time/
> >
> > Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony"
> would be more secure and sustainable.
> >
>
> Oops, I actually confused cron and chrony here. Interestingly, the
> question "can't systemd do that?" remained valid :).
>
> I agree to pick the more mature solution for this purpose.
>
> >>>    suricata:
> >>>      bin_pkgs:
> >>>        suricata:
> >>>          depends:
> >>>          - dpkg
> >>>          - python
> >>>          - python-simplejson
> >>
> >> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> >> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in
> our list already?
> >
> > @kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> and @Dinesh Kumar,
> > Do you need a script modification to address this issue?

We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

> > Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
> in the security working group.
> > The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
>
> We can only decide about package sets which have their runtime
> dependencies already fulfilled with the existing package set (where is
> that now, BTW?) or include these dependencies in the set.

I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
   from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
   (e.g. If following this, the security package proposal pulls around 90 packages finally)

> I only checked
> suricata because of the outstanding python dependency, but there might
> be more issue. This needs to be checked carefully again.

Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members become clear.

Kazu

>
> Jan
>
> >
> > Best regards,
> > Kent
> > -----Original Message-----
> > From: cip-dev <cip-dev-bounces at lists.cip-project.org<mailto:cip-dev-bounces@lists.cip-project.org>> On Behalf Of Jan Kiszka
> > Sent: Thursday, December 19, 2019 7:48 PM
> > To: kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>; cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
> > Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >
> > On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> wrote:
> >> Hello CIP Core members,
> >>
> >> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> >> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> >> p.md#phase-2-proposal-review
> >>
> >> The packages are proposed by CIP security WG to satisfy their required features.
> >> See the "reason" fields in the proposal for more details.
> >>
> >> Please reply with you opinion, agree or disagree.
> >> If you cannot agree to add specific packages, please show the reasons as well.
> >>
> >> Due Date: December 23rd
> >> (We can extend this due date if more time required for reviews, please
> >> let me know if any requests)
> >>
> >
> > [...]
> >
> >>    chrony:
> >>      bin_pkgs:
> >>        chrony:
> >>          depends:
> >>          - init-system-helpers
> >>          - adduser
> >>          - iproute2
> >>          - lsb-base
> >>          - ucf
> >>          - libc6
> >>          - libcap2
> >>          - libedit2
> >>          - libnettle6
> >>          - libseccomp2
> >>      in_target: 'True'
> >>      n_cve: '10'
> >>      reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >>      security_criteria: network::server, network::service
> >
> > Why still chrony, why not simply systemd timers? Legacy?
> >
> >>    suricata:
> >>      bin_pkgs:
> >>        suricata:
> >>          depends:
> >>          - dpkg
> >>          - python
> >>          - python-simplejson
> >
> > I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> currently even
> > v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> >
> > Jan
> >
>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20191222/2dd7606a/attachment.html>

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[kazuhiro3.hayashi at toshiba.co.jp]

Good morning Kudo-san,

>> So, please suspend this proposal process until requirements of all members become clear.
> Does this means that the above due date is extended and the new due date will be announced later?

Yes. I will share the new due date ASAP, but it would be a day in January...

Best regards,
Kazu

From: masashi.kudo@cybertrust.co.jp [mailto:masashi.kudo at cybertrust.co.jp]
Sent: Monday, December 23, 2019 7:59 AM
To: hayashi kazuhiro(? ?? ????????) <kazuhiro3.hayashi@toshiba.co.jp>
Cc: jan.kiszka at siemens.com; kento.yoshida.wz at renesas.com; cip-dev at lists.cip-project.org; dinesh kumar(???? DS Company) <dinesh.kumar@toshiba-tsip.com>
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Kazu-san,

Thanks for working on this.

  > Due Date: December 23rd
Originally, the due date was today.

> So, please suspend this proposal process until requirements of all members become clear.
Does this means that the above due date is extended and the new due date will be announced later?
Just to make sure.

Best regards,
--
M. Kudo


2019?12?20?(?) 18:59 <kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>>:
Hello,

> On 20.12.19 03:25, Kento Yoshida wrote:
> > Thank you for your feedback, Jan.
> >
> >> Why still chrony, why not simply systemd timers? Legacy?
> >
> > We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> > The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized
> by CII as being a superior secure NTP implementation.
> > https://www.coreinfrastructure.org/blogs/securing-network-time/
> >
> > Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony"
> would be more secure and sustainable.
> >
>
> Oops, I actually confused cron and chrony here. Interestingly, the
> question "can't systemd do that?" remained valid :).
>
> I agree to pick the more mature solution for this purpose.
>
> >>>    suricata:
> >>>      bin_pkgs:
> >>>        suricata:
> >>>          depends:
> >>>          - dpkg
> >>>          - python
> >>>          - python-simplejson
> >>
> >> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> >> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in
> our list already?
> >
> > @kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> and @Dinesh Kumar,
> > Do you need a script modification to address this issue?

We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

> > Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
> in the security working group.
> > The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
>
> We can only decide about package sets which have their runtime
> dependencies already fulfilled with the existing package set (where is
> that now, BTW?) or include these dependencies in the set.

I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
   from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
   (e.g. If following this, the security package proposal pulls around 90 packages finally)

> I only checked
> suricata because of the outstanding python dependency, but there might
> be more issue. This needs to be checked carefully again.

Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members become clear.

Kazu

>
> Jan
>
> >
> > Best regards,
> > Kent
> > -----Original Message-----
> > From: cip-dev <cip-dev-bounces at lists.cip-project.org<mailto:cip-dev-bounces@lists.cip-project.org>> On Behalf Of Jan Kiszka
> > Sent: Thursday, December 19, 2019 7:48 PM
> > To: kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>; cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
> > Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >
> > On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> wrote:
> >> Hello CIP Core members,
> >>
> >> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> >> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> >> p.md#phase-2-proposal-review
> >>
> >> The packages are proposed by CIP security WG to satisfy their required features.
> >> See the "reason" fields in the proposal for more details.
> >>
> >> Please reply with you opinion, agree or disagree.
> >> If you cannot agree to add specific packages, please show the reasons as well.
> >>
> >> Due Date: December 23rd
> >> (We can extend this due date if more time required for reviews, please
> >> let me know if any requests)
> >>
> >
> > [...]
> >
> >>    chrony:
> >>      bin_pkgs:
> >>        chrony:
> >>          depends:
> >>          - init-system-helpers
> >>          - adduser
> >>          - iproute2
> >>          - lsb-base
> >>          - ucf
> >>          - libc6
> >>          - libcap2
> >>          - libedit2
> >>          - libnettle6
> >>          - libseccomp2
> >>      in_target: 'True'
> >>      n_cve: '10'
> >>      reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >>      security_criteria: network::server, network::service
> >
> > Why still chrony, why not simply systemd timers? Legacy?
> >
> >>    suricata:
> >>      bin_pkgs:
> >>        suricata:
> >>          depends:
> >>          - dpkg
> >>          - python
> >>          - python-simplejson
> >
> > I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> currently even
> > v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> >
> > Jan
> >
>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20191222/b8391513/attachment-0001.html>

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[masashi.kudo at cybertrust.co.jp]

Kazu-san,

I understood. Thanks very much!
--
M. Kudo

2019?12?23?(?) 8:43 <kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>>:
Good morning Kudo-san,

>> So, please suspend this proposal process until requirements of all members become clear.
> Does this means that the above due date is extended and the new due date will be announced later?

Yes. I will share the new due date ASAP, but it would be a day in January...

Best regards,
Kazu

From: masashi.kudo@cybertrust.co.jp<mailto:masashi.kudo@cybertrust.co.jp> [mailto:masashi.kudo at cybertrust.co.jp<mailto:masashi.kudo@cybertrust.co.jp>]
Sent: Monday, December 23, 2019 7:59 AM
To: hayashi kazuhiro(? ?? ????????) <kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>>
Cc: jan.kiszka at siemens.com<mailto:jan.kiszka@siemens.com>; kento.yoshida.wz at renesas.com<mailto:kento.yoshida.wz@renesas.com>; cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>; dinesh kumar(???? DS Company) <dinesh.kumar at toshiba-tsip.com<mailto:dinesh.kumar@toshiba-tsip.com>>
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

Kazu-san,

Thanks for working on this.

  > Due Date: December 23rd
Originally, the due date was today.

> So, please suspend this proposal process until requirements of all members become clear.
Does this means that the above due date is extended and the new due date will be announced later?
Just to make sure.

Best regards,
--
M. Kudo


2019?12?20?(?) 18:59 <kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>>:
Hello,

> On 20.12.19 03:25, Kento Yoshida wrote:
> > Thank you for your feedback, Jan.
> >
> >> Why still chrony, why not simply systemd timers? Legacy?
> >
> > We agree that systemd-timesyncd is sufficient for users who need only SNTP client functionality.
> > The reason we want to add Chrony to our core packages is to support various use cases, and because Chrony is recognized
> by CII as being a superior secure NTP implementation.
> > https://www.coreinfrastructure.org/blogs/securing-network-time/
> >
> > Since the CII aims to invest in core infrastructure, providing funding for fundamental projects, I think "chrony"
> would be more secure and sustainable.
> >
>
> Oops, I actually confused cron and chrony here. Interestingly, the
> question "can't systemd do that?" remained valid :).
>
> I agree to pick the more mature solution for this purpose.
>
> >>>    suricata:
> >>>      bin_pkgs:
> >>>        suricata:
> >>>          depends:
> >>>          - dpkg
> >>>          - python
> >>>          - python-simplejson
> >>
> >> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> >> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this in
> our list already?
> >
> > @kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> and @Dinesh Kumar,
> > Do you need a script modification to address this issue?

We need to reconsider the format of proposal.yml (and scripts as well).
It seems not to be reviewed enough.

> > Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under investigation
> in the security working group.
> > The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
>
> We can only decide about package sets which have their runtime
> dependencies already fulfilled with the existing package set (where is
> that now, BTW?) or include these dependencies in the set.

I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
If so, there is no such list because this is the first proposal.

Also, it's difficult for me to agree with the opinion that
"all runtime dependencies must be fullfilled with the existing package set" because
1) Some dependency (binary) packages are not functionally necessary
   from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
2) The list including all dependencies may become big for CIP's "OSBL"
   (e.g. If following this, the security package proposal pulls around 90 packages finally)

> I only checked
> suricata because of the outstanding python dependency, but there might
> be more issue. This needs to be checked carefully again.

Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
I will prepare this and will share in the next week.

So, please suspend this proposal process until requirements of all members become clear.

Kazu

>
> Jan
>
> >
> > Best regards,
> > Kent
> > -----Original Message-----
> > From: cip-dev <cip-dev-bounces at lists.cip-project.org<mailto:cip-dev-bounces@lists.cip-project.org>> On Behalf Of Jan Kiszka
> > Sent: Thursday, December 19, 2019 7:48 PM
> > To: kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp>; cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
> > Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >
> > On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp<mailto:kazuhiro3.hayashi@toshiba.co.jp> wrote:
> >> Hello CIP Core members,
> >>
> >> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> >> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> >> p.md#phase-2-proposal-review
> >>
> >> The packages are proposed by CIP security WG to satisfy their required features.
> >> See the "reason" fields in the proposal for more details.
> >>
> >> Please reply with you opinion, agree or disagree.
> >> If you cannot agree to add specific packages, please show the reasons as well.
> >>
> >> Due Date: December 23rd
> >> (We can extend this due date if more time required for reviews, please
> >> let me know if any requests)
> >>
> >
> > [...]
> >
> >>    chrony:
> >>      bin_pkgs:
> >>        chrony:
> >>          depends:
> >>          - init-system-helpers
> >>          - adduser
> >>          - iproute2
> >>          - lsb-base
> >>          - ucf
> >>          - libc6
> >>          - libcap2
> >>          - libedit2
> >>          - libnettle6
> >>          - libseccomp2
> >>      in_target: 'True'
> >>      n_cve: '10'
> >>      reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >>      security_criteria: network::server, network::service
> >
> > Why still chrony, why not simply systemd timers? Legacy?
> >
> >>    suricata:
> >>      bin_pkgs:
> >>        suricata:
> >>          depends:
> >>          - dpkg
> >>          - python
> >>          - python-simplejson
> >
> > I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> currently even
> > v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> >
> > Jan
> >
>
>
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux
_______________________________________________
cip-dev mailing list
cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev at lists.cip-project.org<mailto:cip-dev@lists.cip-project.org>
https://lists.cip-project.org/mailman/listinfo/cip-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20191223/dcc53d5b/attachment-0001.html>

[cip-dev] [cip-core] Package Proposal #1 (Security packages)

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Jan and CIP core members,

> Hi all,
> 
> On 20.12.19 10:58, kazuhiro3.hayashi at toshiba.co.jp wrote:
> >>>>>     suricata:
> >>>>>       bin_pkgs:
> >>>>>         suricata:
> >>>>>           depends:
> >>>>>           - dpkg
> >>>>>           - python
> >>>>>           - python-simplejson
> >>>>
> >>>> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat?
> >>>> This, e.g., pulls python, currently even v2 - anything but a trivial package. Or did I miss that we have this
> in
> >> our list already?
> >>>
> >>> @kazuhiro3.hayashi at toshiba.co.jp and @Dinesh Kumar,
> >>> Do you need a script modification to address this issue?
> >
> > We need to reconsider the format of proposal.yml (and scripts as well).
> > It seems not to be reviewed enough.
> >
> >>> Actually, proposals for run-time dependencies package of top-lists are still in preparation and are under
> investigation
> >> in the security working group.
> >>> The automatic outputs of the script have been used as it is for the dependencies package displayed in this proposal.
> >>
> >> We can only decide about package sets which have their runtime
> >> dependencies already fulfilled with the existing package set (where is
> >> that now, BTW?) or include these dependencies in the set.
> >
> > I'm assuming the "existing package set" is the list of packages that are already accepted by CIP.
> > If so, there is no such list because this is the first proposal.
> 
> Then let's define that base (minimal debootstrap) first before adding
> further packages.

OK, let's start from defining this base.

> 
> >
> > Also, it's difficult for me to agree with the opinion that
> > "all runtime dependencies must be fullfilled with the existing package set" because
> > 1) Some dependency (binary) packages are not functionally necessary
> >     from the CIP's long-term support point of view (debconf, debian-archive-keyring, etc.)
> 
> Anything that a Debian package requires needs to be present - otherwise
> the package becomes broken. I can't imagine we want to propose that to
> our users. Weaker dependencies are obviously optional.

Yes, anything required by Debian package needs to be "present",
but it is not always necessary to "maintain" their source
(e.g. Request them to Debian Extended LTS).

I think that there are two kinds in our "support" levels:
(1) Just make the package available (present) in CIP at least 10 years
(2) (1) + Keep watching the latest bugs and security issues and fixing them aggressively
I was understanding that the CIP package list we are discussing is
for clarifying the packages like (2).
However, if no one in CIP care about the difference between (1) and (2),
we should simply define the package list including all binary package dependencies, like Jan mentioned.

> 
> If we should run into a package that seems to require more than it
> should, let's improve it by proposing a break-up upstream. Or by
> repackaging it in meta-debian / isar-cip-core. But that should come
> first before proposing it here.

It would be better if the both profiles can have such improved packages,
but actually changing upstream (Debian) takes much time and effort and
repackaging by ourselves may bring big impacts to package compatibilities,
especially in the generic profile.

> 
> > 2) The list including all dependencies may become big for CIP's "OSBL"
> >     (e.g. If following this, the security package proposal pulls around 90 packages finally)
> 
> Anything in that range still seems reasonable from a maintenance
> perspective - provided there are no "challenging" packages included. But
> we should still check if that number is seriously needed, though.

OK, let's discuss about this number in the future proposal.

Anyway, I will create and share a sample of proposal.yml with the flat package set,
please review that and confirm if it matches your opinion of the "CIP maintained packages".

Kazu

> 
> Jan
> 
> >
> >> I only checked
> >> suricata because of the outstanding python dependency, but there might
> >> be more issue. This needs to be checked carefully again.
> >
> > Yes, we need to share the concrete examples of packages, PDP steps, and the format of yml.
> > I will prepare this and will share in the next week.
> >
> > So, please suspend this proposal process until requirements of all members become clear.
> >
> > Kazu
> >
> >>
> >> Jan
> >>
> >>>
> >>> Best regards,
> >>> Kent
> >>> -----Original Message-----
> >>> From: cip-dev <cip-dev-bounces@lists.cip-project.org> On Behalf Of Jan Kiszka
> >>> Sent: Thursday, December 19, 2019 7:48 PM
> >>> To: kazuhiro3.hayashi at toshiba.co.jp; cip-dev at lists.cip-project.org
> >>> Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >>>
> >>> On 09.12.19 14:54, kazuhiro3.hayashi at toshiba.co.jp wrote:
> >>>> Hello CIP Core members,
> >>>>
> >>>> I would like to start the "review" phase (Phase 2) of the attached package proposal.
> >>>> https://gitlab.com/cip-project/cip-core/cip-pkglist/blob/master/doc/pd
> >>>> p.md#phase-2-proposal-review
> >>>>
> >>>> The packages are proposed by CIP security WG to satisfy their required features.
> >>>> See the "reason" fields in the proposal for more details.
> >>>>
> >>>> Please reply with you opinion, agree or disagree.
> >>>> If you cannot agree to add specific packages, please show the reasons as well.
> >>>>
> >>>> Due Date: December 23rd
> >>>> (We can extend this due date if more time required for reviews, please
> >>>> let me know if any requests)
> >>>>
> >>>
> >>> [...]
> >>>
> >>>>     chrony:
> >>>>       bin_pkgs:
> >>>>         chrony:
> >>>>           depends:
> >>>>           - init-system-helpers
> >>>>           - adduser
> >>>>           - iproute2
> >>>>           - lsb-base
> >>>>           - ucf
> >>>>           - libc6
> >>>>           - libcap2
> >>>>           - libedit2
> >>>>           - libnettle6
> >>>>           - libseccomp2
> >>>>       in_target: 'True'
> >>>>       n_cve: '10'
> >>>>       reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
> >>>>       security_criteria: network::server, network::service
> >>>
> >>> Why still chrony, why not simply systemd timers? Legacy?
> >>>
> >>>>     suricata:
> >>>>       bin_pkgs:
> >>>>         suricata:
> >>>>           depends:
> >>>>           - dpkg
> >>>>           - python
> >>>>           - python-simplejson
> >>>
> >>> I'm missing the new dependencies in the top-list. Didn't we agree on listing them flat? This, e.g., pulls python,
> >> currently even
> >>> v2 - anything but a trivial package. Or did I miss that we have this in our list already?
> >>>
> >>> Jan
> >>>
> >>
> >>
> >> --
> >> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> >> Corporate Competence Center Embedded Linux
> 
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux