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

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

[Kento Yoshida]

Hello,

I would like to resume our proposal from security working group.
As you know, Kazu has modified the script to generate a proposal and posted the minimum base system proposal, and then I created the new proposal.

The difference from the original (rev01) proposal is below:
1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the new proposal because they have an issue such as non-well maintained, python version, too much dependencies and so on. We'll separately propose them after solved these issues.
2. The new proposal shows all source package as flat. Thanks to the new script, Kazu!
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment them like that.

@kazuhiro3.hayashi at toshiba.co.jp,
Would you check this proposal and set the due date to review it?

Please reply if you have any comments or questions.

Kind regards,
Kent

>-----Original Message-----
From: kazuhiro3.hayashi@toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
>Sent: Friday, December 20, 2019 6:59 PM
>To: jan.kiszka at siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
>cip-dev at lists.cip-project.org; dinesh.kumar at toshiba-tsip.com
>Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
>
>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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proposal_security_rev02.yml
Type: application/octet-stream
Size: 29797 bytes
Desc: proposal_security_rev02.yml
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200117/1b50a3f3/attachment-0001.obj>

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

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Kent,

[...]
> 3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
> them like that.

Thank you for taking time to check this...
In order to clearly show the differences of my proposal #2 and your proposal,
it might be better to create additional yml file where the duplicated packages are dropped.
I will try to create this data next week :)

> 
> @kazuhiro3.hayashi at toshiba.co.jp,
> Would you check this proposal and set the due date to review it?

The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
but how about setting it to Jan 27th?

Best regards,
Kazu

> 
> Please reply if you have any comments or questions.
> 
> Kind regards,
> Kent
> 
> >-----Original Message-----
> >From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
> >Sent: Friday, December 20, 2019 6:59 PM
> >To: jan.kiszka at siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
> >cip-dev at lists.cip-project.org; dinesh.kumar at toshiba-tsip.com
> >Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >
> >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] RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

[Jan Kiszka]

On 17.01.20 14:14, kazuhiro3.hayashi at toshiba.co.jp wrote:
> Hello Kent,
> 
> [...]
>> 3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
>> them like that.
> 
> Thank you for taking time to check this...
> In order to clearly show the differences of my proposal #2 and your proposal,
> it might be better to create additional yml file where the duplicated packages are dropped.
> I will try to create this data next week :)
> 
>>
>> @kazuhiro3.hayashi at toshiba.co.jp,
>> Would you check this proposal and set the due date to review it?
> 
> The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
> but how about setting it to Jan 27th?

As I'm not in the house next week, I will not be able to comment on the 
new list, nor vote. In any case, one week might be ok for a short, 
obvious list. But if we are talking about a list of dozens of packages, 
that will be too short.

Jan

> 
> Best regards,
> Kazu
> 
>>
>> Please reply if you have any comments or questions.
>>
>> Kind regards,
>> Kent
>>
>>> -----Original Message-----
>>> From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
>>> Sent: Friday, December 20, 2019 6:59 PM
>>> To: jan.kiszka at siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
>>> cip-dev at lists.cip-project.org; dinesh.kumar at toshiba-tsip.com
>>> Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
>>>
>>> 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 mailing list
> cip-dev at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-dev
> 

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

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

[Punit Agrawal]

Hello Yoshida-san,

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

> Hello,
>
> I would like to resume our proposal from security working group.
> As you know, Kazu has modified the script to generate a proposal and posted the minimum base system proposal, and then I created the new proposal.
>
> The difference from the original (rev01) proposal is below:
> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the new proposal because they have an issue such as non-well maintained, python version, too much dependencies and so on. We'll separately propose them after solved these issues.
> 2. The new proposal shows all source package as flat. Thanks to the new script, Kazu!
> 3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment them like that.
>
> @kazuhiro3.hayashi at toshiba.co.jp,
> Would you check this proposal and set the due date to review it?
>
> Please reply if you have any comments or questions.

I have a comment about packages in the proposal that depend on hardware
/ system features -

* Some packages in the proposal depend on special purpose hardware to
  provide their functionality. e.g., TPM.

  In systems, where TPM is not present (or similar functionality is
  provided by alternate mechanisms), the TPM related packages will not
  be useful. e.g., the non-x86 platforms in the CIP reference hardware
  list.

* Similarly, some packages require the system to be connected to the
  network.

In both of these situations, I am wondering what is the impact on
compliance? Is there a need to also define minimal set of hardware
features expected from reference hardware to be able to meet compliance
requirements?

To help review the package list (and also discuss alternatives), it
would help to define the underlying functionality that is required in
more detail, e.g., secure key storage, verified boot, etc. It'll make it
possible review the proposal more concretely.

Thoughts?

Thanks,
Punit

[...]

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

[kazuhiro3.hayashi at toshiba.co.jp]

Hello,

> On 17.01.20 14:14, kazuhiro3.hayashi at toshiba.co.jp wrote:
> > Hello Kent,
> >
> > [...]
> >> 3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added comment
> >> them like that.
> >
> > Thank you for taking time to check this...
> > In order to clearly show the differences of my proposal #2 and your proposal,
> > it might be better to create additional yml file where the duplicated packages are dropped.
> > I will try to create this data next week :)
> >
> >>
> >> @kazuhiro3.hayashi at toshiba.co.jp,
> >> Would you check this proposal and set the due date to review it?
> >
> > The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
> > but how about setting it to Jan 27th?
> 
> As I'm not in the house next week, I will not be able to comment on the
> new list, nor vote. In any case, one week might be ok for a short,
> obvious list. But if we are talking about a list of dozens of packages,
> that will be too short.

Thank you for your reply.

I would like to change the due date to
	Feb 5th (two weeks + 3 days)
Regarding security packages, I guess more discussions about
the technical requirements of the security standard would be required,
so this change might not be enough too though.

Kazu

> 
> Jan
> 
> >
> > Best regards,
> > Kazu
> >
> >>
> >> Please reply if you have any comments or questions.
> >>
> >> Kind regards,
> >> Kent
> >>
> >>> -----Original Message-----
> >>> From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
> >>> Sent: Friday, December 20, 2019 6:59 PM
> >>> To: jan.kiszka at siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
> >>> cip-dev at lists.cip-project.org; dinesh.kumar at toshiba-tsip.com
> >>> Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> >>>
> >>> 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 mailing list
> > cip-dev at lists.cip-project.org
> > https://lists.cip-project.org/mailman/listinfo/cip-dev
> >
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

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

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Kent, and reviewers,

[...]
> In order to clearly show the differences of my proposal #2 and your proposal,
> it might be better to create additional yml file where the duplicated packages are dropped.
> I will try to create this data next week :)

I attached this file.
Please note that the packages duplicated with the proposal #2 are removed from this file.

As the first step, it's better to start our reviews from
the 15 "top-level" packages in the first section of the attachment.
Other packages are just dependencies of these packages.

Best regards,
Kazu

> 
> >
> > @kazuhiro3.hayashi at toshiba.co.jp,
> > Would you check this proposal and set the due date to review it?
> 
> The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
> but how about setting it to Jan 27th?
> 
> Best regards,
> Kazu
> 
> >
> > Please reply if you have any comments or questions.
> >
> > Kind regards,
> > Kent
> >
> > >-----Original Message-----
> > >From: kazuhiro3.hayashi at toshiba.co.jp <kazuhiro3.hayashi@toshiba.co.jp>
> > >Sent: Friday, December 20, 2019 6:59 PM
> > >To: jan.kiszka at siemens.com; Kento Yoshida <kento.yoshida.wz@renesas.com>;
> > >cip-dev at lists.cip-project.org; dinesh.kumar at toshiba-tsip.com
> > >Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
> > >
> > >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-security mailing list
> Cip-security at lists.cip-project.org
> https://lists.cip-project.org/mailman/listinfo/cip-security
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proposal_security_20200117_simplified.txt
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200121/e5eeae2c/attachment-0001.txt>

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

[Kento Yoshida]

Hello and thank you for your comment, Punit,

>-----Original Message-----
>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>Sent: Monday, January 20, 2020 7:29 PM
>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
>cip-security at lists.cip-project.org
>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
>packages)
>
>Hello Yoshida-san,
>
>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>
>> Hello,
>>
>> I would like to resume our proposal from security working group.
>> As you know, Kazu has modified the script to generate a proposal and posted the
>minimum base system proposal, and then I created the new proposal.
>>
>> The difference from the original (rev01) proposal is below:
>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the
>new proposal because they have an issue such as non-well maintained, python
>version, too much dependencies and so on. We'll separately propose them after
>solved these issues.
>> 2. The new proposal shows all source package as flat. Thanks to the new script,
>Kazu!
>> 3. Actually several packages overlap with the proposed packages for minimum
>base system in Debian, so I added comment them like that.
>>
>> @kazuhiro3.hayashi at toshiba.co.jp,
>> Would you check this proposal and set the due date to review it?
>>
>> Please reply if you have any comments or questions.
>
>I have a comment about packages in the proposal that depend on hardware /
>system features -
>
>* Some packages in the proposal depend on special purpose hardware to
>  provide their functionality. e.g., TPM.
>
>  In systems, where TPM is not present (or similar functionality is
>  provided by alternate mechanisms), the TPM related packages will not
>  be useful. e.g., the non-x86 platforms in the CIP reference hardware
>  list.
>
>* Similarly, some packages require the system to be connected to the
>  network.
>
>In both of these situations, I am wondering what is the impact on compliance? Is
>there a need to also define minimal set of hardware features expected from
>reference hardware to be able to meet compliance requirements?
>

How each reference hardware satisfies the requirements should be considered by each reference hardware provider.
If we provide hardware mechanisms similar with TPM to protect credentials and authentications, we can meet compliance requirements.
TPM related packages are options in only systems where TPM is implemented as you said. If supporting these packages require too much costs, the necessity of them will diminish.
Actually the standard lists TPM as a typical example, so we thought it will be useful to maintain TPM related packages for many users, but their necessities depend on supporting cost.

>To help review the package list (and also discuss alternatives), it would help to
>define the underlying functionality that is required in more detail, e.g., secure key
>storage, verified boot, etc. It'll make it possible review the proposal more
>concretely.
>
>Thoughts?
>
>Thanks,
>Punit
>
>[...]
>

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

[Punit Agrawal]

Thank you for your comments, Yoshida-san. Follow up comments inline.

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

> Hello and thank you for your comment, Punit,
>
>>-----Original Message-----
>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>Sent: Monday, January 20, 2020 7:29 PM
>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
>>cip-security at lists.cip-project.org
>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
>>packages)
>>
>>Hello Yoshida-san,
>>
>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>
>>> Hello,
>>>
>>> I would like to resume our proposal from security working group.
>>> As you know, Kazu has modified the script to generate a proposal and posted the
>>minimum base system proposal, and then I created the new proposal.
>>>
>>> The difference from the original (rev01) proposal is below:
>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 'suricata' in the
>>new proposal because they have an issue such as non-well maintained, python
>>version, too much dependencies and so on. We'll separately propose them after
>>solved these issues.
>>> 2. The new proposal shows all source package as flat. Thanks to the new script,
>>Kazu!
>>> 3. Actually several packages overlap with the proposed packages for minimum
>>base system in Debian, so I added comment them like that.
>>>
>>> @kazuhiro3.hayashi at toshiba.co.jp,
>>> Would you check this proposal and set the due date to review it?
>>>
>>> Please reply if you have any comments or questions.
>>
>>I have a comment about packages in the proposal that depend on hardware /
>>system features -
>>
>>* Some packages in the proposal depend on special purpose hardware to
>>  provide their functionality. e.g., TPM.
>>
>>  In systems, where TPM is not present (or similar functionality is
>>  provided by alternate mechanisms), the TPM related packages will not
>>  be useful. e.g., the non-x86 platforms in the CIP reference hardware
>>  list.
>>
>>* Similarly, some packages require the system to be connected to the
>>  network.
>>
>>In both of these situations, I am wondering what is the impact on compliance? Is
>>there a need to also define minimal set of hardware features expected from
>>reference hardware to be able to meet compliance requirements?
>>
>
> How each reference hardware satisfies the requirements should be
> considered by each reference hardware provider.

Agreed.

But without an explicit statement of the requirement, how can a hardware
vendor wanting to develop system for CIP users know what features to
enable in their system?

> If we provide hardware mechanisms similar with TPM to protect
> credentials and authentications, we can meet compliance requirements.

TPM2 specification is more than 2000 pages long with many features and
functions. I believe the IEC standard requires a subset of this
functionality. The Security WG maybe intimately familiar with the
required features but for the reviewers on this list, there isn't any
criteria to use for evaluation.

Stating these functional requirements explicitly will serve the dual
purpose of -

* Provide an objective criteria for evaluating the package proposal (and
  discuss alternatives)

* Give hardware / system vendors the features / functions needed by CIP
  users.

What do you think?

> TPM related packages are options in only systems where TPM is
> implemented as you said. If supporting these packages require too much
> costs, the necessity of them will diminish.  Actually the standard
> lists TPM as a typical example, so we thought it will be useful to
> maintain TPM related packages for many users, but their necessities
> depend on supporting cost.

I see - thanks for the background of the TPM-related packages in the
proposal.

>
>>To help review the package list (and also discuss alternatives), it would help to
>>define the underlying functionality that is required in more detail, e.g., secure key
>>storage, verified boot, etc. It'll make it possible review the proposal more
>>concretely.

[...]

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

[Kento Yoshida]

Hello reviews,

Thank you for your supporting against our proposal.
I'd like to share you the description sheet for our proposal of security packages.
Please consider my attachment and the following note.

Note:
1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not well-maintained and replace with "fail2ban"
2. There are 3 packages in bottom that are under discussion to add. They are out of scope for this review but I'd like to explain them, so let me know your ideas if you have.
3. The requirements for hardware functions are out of scope for this review, but tpm2 is concrete example mentioned in the standard, so I'd like to add some packages related tpm2. However, they are options for only using tpm2, so let me know your comments against adding the packages for a specific use case.

BTW,

@kazuhiro3.hayashi at toshiba.co.jp,

I'd like to create new proposal to add "fail2ban", but the script for generating proposal shows the following error, and I could not generate it.

-------------------------------
Source package name:
Binary packages:

any>
Traceback (most recent call last):
  File "./generate-proposal.py", line 218, in <module>
    generate_proposal(common.PDPProposal.ProposalInfo())
  File "./generate-proposal.py", line 176, in generate_proposal
    deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg, dep_pkg_info.keys())
  File "./generate-proposal.py", line 51, in prepare_src_pkg_info
    dp_list_final = gpd.get_pkg_depends(pkg, apt)
  File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in get_pkg_depends
    dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
  File "/home/yoshidak/cip-pkglist/common.py", line 222, in apt_cache_get_depends_list
    dp_info=c[pkg_name]
  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
    raise KeyError('The cache has no package named %r' % key)
KeyError: "The cache has no package named 'any>'"
-------------------------------

I think that the reason is below. When I enter the information of "fail2ban", the script get the dependency for it as <python3:any>.

-------------------------------
Enter the source package name: fail2ban
Choose the required binary packages:
        1: fail2ban
 Input the numbers in comma separated (eg: 1,3,4): 1

fail2ban
 Choose one of the virtual package provider: <python3:any>
        1: python3
 Input the number: 1
        -<python3:any>:python3
        -lsb-base
 Are any of the binary packages used in target rootfs?
        1: True
        2: False
-------------------------------

Would you confirm this issue?

Best regards,
Kent

>-----Original Message-----
>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>Sent: Thursday, January 23, 2020 4:35 PM
>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>Cc: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
>packages)
>
>Thank you for your comments, Yoshida-san. Follow up comments inline.
>
>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>
>> Hello and thank you for your comment, Punit,
>>
>>>-----Original Message-----
>>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>>Sent: Monday, January 20, 2020 7:29 PM
>>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
>>>cip-security at lists.cip-project.org
>>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
>>>(Security
>>>packages)
>>>
>>>Hello Yoshida-san,
>>>
>>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>>
>>>> Hello,
>>>>
>>>> I would like to resume our proposal from security working group.
>>>> As you know, Kazu has modified the script to generate a proposal and
>>>> posted the
>>>minimum base system proposal, and then I created the new proposal.
>>>>
>>>> The difference from the original (rev01) proposal is below:
>>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and
>>>> 'suricata' in the
>>>new proposal because they have an issue such as non-well maintained,
>>>python version, too much dependencies and so on. We'll separately
>>>propose them after solved these issues.
>>>> 2. The new proposal shows all source package as flat. Thanks to the
>>>> new script,
>>>Kazu!
>>>> 3. Actually several packages overlap with the proposed packages for
>>>> minimum
>>>base system in Debian, so I added comment them like that.
>>>>
>>>> @kazuhiro3.hayashi at toshiba.co.jp,
>>>> Would you check this proposal and set the due date to review it?
>>>>
>>>> Please reply if you have any comments or questions.
>>>
>>>I have a comment about packages in the proposal that depend on
>>>hardware / system features -
>>>
>>>* Some packages in the proposal depend on special purpose hardware to
>>>  provide their functionality. e.g., TPM.
>>>
>>>  In systems, where TPM is not present (or similar functionality is
>>> provided by alternate mechanisms), the TPM related packages will not
>>> be useful. e.g., the non-x86 platforms in the CIP reference hardware
>>> list.
>>>
>>>* Similarly, some packages require the system to be connected to the
>>>  network.
>>>
>>>In both of these situations, I am wondering what is the impact on
>>>compliance? Is there a need to also define minimal set of hardware
>>>features expected from reference hardware to be able to meet compliance
>requirements?
>>>
>>
>> How each reference hardware satisfies the requirements should be
>> considered by each reference hardware provider.
>
>Agreed.
>
>But without an explicit statement of the requirement, how can a hardware vendor
>wanting to develop system for CIP users know what features to enable in their
>system?
>
>> If we provide hardware mechanisms similar with TPM to protect
>> credentials and authentications, we can meet compliance requirements.
>
>TPM2 specification is more than 2000 pages long with many features and
>functions. I believe the IEC standard requires a subset of this functionality. The
>Security WG maybe intimately familiar with the required features but for the
>reviewers on this list, there isn't any criteria to use for evaluation.
>
>Stating these functional requirements explicitly will serve the dual purpose of -
>
>* Provide an objective criteria for evaluating the package proposal (and
>  discuss alternatives)
>
>* Give hardware / system vendors the features / functions needed by CIP
>  users.
>
>What do you think?
>
>> TPM related packages are options in only systems where TPM is
>> implemented as you said. If supporting these packages require too much
>> costs, the necessity of them will diminish.  Actually the standard
>> lists TPM as a typical example, so we thought it will be useful to
>> maintain TPM related packages for many users, but their necessities
>> depend on supporting cost.
>
>I see - thanks for the background of the TPM-related packages in the proposal.
>
>>
>>>To help review the package list (and also discuss alternatives), it
>>>would help to define the underlying functionality that is required in
>>>more detail, e.g., secure key storage, verified boot, etc. It'll make
>>>it possible review the proposal more concretely.
>
>[...]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: description for proposal #1 from security wg.xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 13852 bytes
Desc: description for proposal #1 from security wg.xlsx
URL: <http://lists.cip-project.org/pipermail/cip-dev/attachments/20200207/95fcdc47/attachment-0001.xlsx>

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

[kazuhiro3.hayashi at toshiba.co.jp]

Hello Kent,

Thank you for reporting the problem.
I've created an issue on GitLab: https://gitlab.com/cip-project/cip-core/cip-pkglist/issues/4

However, I could not reproduce the error.
Could you join the discussion above and tell us the commit ID of `cip-pkglist` you are using and host system information?

Best regards,
Kazu
> 
> Hello reviews,
> 
> Thank you for your supporting against our proposal.
> I'd like to share you the description sheet for our proposal of security packages.
> Please consider my attachment and the following note.
> 
> Note:
> 1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not well-maintained and replace with "fail2ban"
> 2. There are 3 packages in bottom that are under discussion to add. They are out of scope for this review but I'd like
> to explain them, so let me know your ideas if you have.
> 3. The requirements for hardware functions are out of scope for this review, but tpm2 is concrete example mentioned in
> the standard, so I'd like to add some packages related tpm2. However, they are options for only using tpm2, so let me
> know your comments against adding the packages for a specific use case.
> 
> BTW,
> 
> @kazuhiro3.hayashi at toshiba.co.jp,
> 
> I'd like to create new proposal to add "fail2ban", but the script for generating proposal shows the following error, and
> I could not generate it.
> 
> -------------------------------
> Source package name:
> Binary packages:
> 
> any>
> Traceback (most recent call last):
>   File "./generate-proposal.py", line 218, in <module>
>     generate_proposal(common.PDPProposal.ProposalInfo())
>   File "./generate-proposal.py", line 176, in generate_proposal
>     deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg, dep_pkg_info.keys())
>   File "./generate-proposal.py", line 51, in prepare_src_pkg_info
>     dp_list_final = gpd.get_pkg_depends(pkg, apt)
>   File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in get_pkg_depends
>     dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
>   File "/home/yoshidak/cip-pkglist/common.py", line 222, in apt_cache_get_depends_list
>     dp_info=c[pkg_name]
>   File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
>     raise KeyError('The cache has no package named %r' % key)
> KeyError: "The cache has no package named 'any>'"
> -------------------------------
> 
> I think that the reason is below. When I enter the information of "fail2ban", the script get the dependency for it as
> <python3:any>.
> 
> -------------------------------
> Enter the source package name: fail2ban
> Choose the required binary packages:
>         1: fail2ban
>  Input the numbers in comma separated (eg: 1,3,4): 1
> 
> fail2ban
>  Choose one of the virtual package provider: <python3:any>
>         1: python3
>  Input the number: 1
>         -<python3:any>:python3
>         -lsb-base
>  Are any of the binary packages used in target rootfs?
>         1: True
>         2: False
> -------------------------------
> 
> Would you confirm this issue?
> 
> Best regards,
> Kent
> 
> >-----Original Message-----
> >From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> >Sent: Thursday, January 23, 2020 4:35 PM
> >To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> >Cc: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
> >Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security
> >packages)
> >
> >Thank you for your comments, Yoshida-san. Follow up comments inline.
> >
> >Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> >
> >> Hello and thank you for your comment, Punit,
> >>
> >>>-----Original Message-----
> >>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
> >>>Sent: Monday, January 20, 2020 7:29 PM
> >>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
> >>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp;
> >>>cip-security at lists.cip-project.org
> >>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1
> >>>(Security
> >>>packages)
> >>>
> >>>Hello Yoshida-san,
> >>>
> >>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
> >>>
> >>>> Hello,
> >>>>
> >>>> I would like to resume our proposal from security working group.
> >>>> As you know, Kazu has modified the script to generate a proposal and
> >>>> posted the
> >>>minimum base system proposal, and then I created the new proposal.
> >>>>
> >>>> The difference from the original (rev01) proposal is below:
> >>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and
> >>>> 'suricata' in the
> >>>new proposal because they have an issue such as non-well maintained,
> >>>python version, too much dependencies and so on. We'll separately
> >>>propose them after solved these issues.
> >>>> 2. The new proposal shows all source package as flat. Thanks to the
> >>>> new script,
> >>>Kazu!
> >>>> 3. Actually several packages overlap with the proposed packages for
> >>>> minimum
> >>>base system in Debian, so I added comment them like that.
> >>>>
> >>>> @kazuhiro3.hayashi at toshiba.co.jp,
> >>>> Would you check this proposal and set the due date to review it?
> >>>>
> >>>> Please reply if you have any comments or questions.
> >>>
> >>>I have a comment about packages in the proposal that depend on
> >>>hardware / system features -
> >>>
> >>>* Some packages in the proposal depend on special purpose hardware to
> >>>  provide their functionality. e.g., TPM.
> >>>
> >>>  In systems, where TPM is not present (or similar functionality is
> >>> provided by alternate mechanisms), the TPM related packages will not
> >>> be useful. e.g., the non-x86 platforms in the CIP reference hardware
> >>> list.
> >>>
> >>>* Similarly, some packages require the system to be connected to the
> >>>  network.
> >>>
> >>>In both of these situations, I am wondering what is the impact on
> >>>compliance? Is there a need to also define minimal set of hardware
> >>>features expected from reference hardware to be able to meet compliance
> >requirements?
> >>>
> >>
> >> How each reference hardware satisfies the requirements should be
> >> considered by each reference hardware provider.
> >
> >Agreed.
> >
> >But without an explicit statement of the requirement, how can a hardware vendor
> >wanting to develop system for CIP users know what features to enable in their
> >system?
> >
> >> If we provide hardware mechanisms similar with TPM to protect
> >> credentials and authentications, we can meet compliance requirements.
> >
> >TPM2 specification is more than 2000 pages long with many features and
> >functions. I believe the IEC standard requires a subset of this functionality. The
> >Security WG maybe intimately familiar with the required features but for the
> >reviewers on this list, there isn't any criteria to use for evaluation.
> >
> >Stating these functional requirements explicitly will serve the dual purpose of -
> >
> >* Provide an objective criteria for evaluating the package proposal (and
> >  discuss alternatives)
> >
> >* Give hardware / system vendors the features / functions needed by CIP
> >  users.
> >
> >What do you think?
> >
> >> TPM related packages are options in only systems where TPM is
> >> implemented as you said. If supporting these packages require too much
> >> costs, the necessity of them will diminish.  Actually the standard
> >> lists TPM as a typical example, so we thought it will be useful to
> >> maintain TPM related packages for many users, but their necessities
> >> depend on supporting cost.
> >
> >I see - thanks for the background of the TPM-related packages in the proposal.
> >
> >>
> >>>To help review the package list (and also discuss alternatives), it
> >>>would help to define the underlying functionality that is required in
> >>>more detail, e.g., secure key storage, verified boot, etc. It'll make
> >>>it possible review the proposal more concretely.
> >
> >[...]

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

[Venkata Seshagiri Pyla]

Hi Kent,

Thanks for reporting the issue in the PDP Scripts.
The issue is already resolved with recent changes in the gitlab.
Could you please git pull the latest changes and try it again.

Kindly please let me know if you are facing any issue.

Thanks,
Venkata.
-----Original Message-----
From: Cip-security [mailto:cip-security-bounces at lists.cip-project.org] On Behalf Of Kento Yoshida
Sent: 07 February 2020 14:28
To: Punit Agrawal <punit1.agrawal@toshiba.co.jp>; kazuhiro3.hayashi at toshiba.co.jp
Cc: cip-security at lists.cip-project.org; cip-dev at lists.cip-project.org
Subject: Re: [Cip-security] [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 (Security packages)

Hello reviews,

Thank you for your supporting against our proposal.
I'd like to share you the description sheet for our proposal of security packages.
Please consider my attachment and the following note.

Note:
1. Added "fail2ban" as the alternative "pam-shield" because "pam-shield" is not well-maintained and replace with "fail2ban"
2. There are 3 packages in bottom that are under discussion to add. They are out of scope for this review but I'd like to explain them, so let me know your ideas if you have.
3. The requirements for hardware functions are out of scope for this review, but tpm2 is concrete example mentioned in the standard, so I'd like to add some packages related tpm2. However, they are options for only using tpm2, so let me know your comments against adding the packages for a specific use case.

BTW,

@kazuhiro3.hayashi at toshiba.co.jp,

I'd like to create new proposal to add "fail2ban", but the script for generating proposal shows the following error, and I could not generate it.

-------------------------------
Source package name:
Binary packages:

any>
Traceback (most recent call last):
  File "./generate-proposal.py", line 218, in <module>
    generate_proposal(common.PDPProposal.ProposalInfo())
  File "./generate-proposal.py", line 176, in generate_proposal
    deb_src_pkg_info = prepare_src_pkg_info(apt, cve, dep_src_pkg, dep_pkg_info.keys())
  File "./generate-proposal.py", line 51, in prepare_src_pkg_info
    dp_list_final = gpd.get_pkg_depends(pkg, apt)
  File "/home/yoshidak/cip-pkglist/get_pkg_depends.py", line 102, in get_pkg_depends
    dp_list, dp_vir_pkg_dict = apt.apt_cache_get_depends_list(pkg_name)
  File "/home/yoshidak/cip-pkglist/common.py", line 222, in apt_cache_get_depends_list
    dp_info=c[pkg_name]
  File "/usr/lib/python2.7/dist-packages/apt/cache.py", line 238, in __getitem__
    raise KeyError('The cache has no package named %r' % key)
KeyError: "The cache has no package named 'any>'"
-------------------------------

I think that the reason is below. When I enter the information of "fail2ban", the script get the dependency for it as <python3:any>.

-------------------------------
Enter the source package name: fail2ban
Choose the required binary packages:
        1: fail2ban
 Input the numbers in comma separated (eg: 1,3,4): 1

fail2ban
 Choose one of the virtual package provider: <python3:any>
        1: python3
 Input the number: 1
        -<python3:any>:python3
        -lsb-base
 Are any of the binary packages used in target rootfs?
        1: True
        2: False
-------------------------------

Would you confirm this issue?

Best regards,
Kent

>-----Original Message-----
>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>Sent: Thursday, January 23, 2020 4:35 PM
>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>Cc: cip-dev at lists.cip-project.org; cip-security at lists.cip-project.org
>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 
>(Security
>packages)
>
>Thank you for your comments, Yoshida-san. Follow up comments inline.
>
>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>
>> Hello and thank you for your comment, Punit,
>>
>>>-----Original Message-----
>>>From: Punit Agrawal <punit1.agrawal@toshiba.co.jp>
>>>Sent: Monday, January 20, 2020 7:29 PM
>>>To: Kento Yoshida <kento.yoshida.wz@renesas.com>
>>>Cc: cip-dev at lists.cip-project.org; kazuhiro3.hayashi at toshiba.co.jp; 
>>>cip-security at lists.cip-project.org
>>>Subject: Re: [cip-dev] RESUME REQUEST: [cip-core] Package Proposal #1 
>>>(Security
>>>packages)
>>>
>>>Hello Yoshida-san,
>>>
>>>Kento Yoshida <kento.yoshida.wz@renesas.com> writes:
>>>
>>>> Hello,
>>>>
>>>> I would like to resume our proposal from security working group.
>>>> As you know, Kazu has modified the script to generate a proposal 
>>>> and posted the
>>>minimum base system proposal, and then I created the new proposal.
>>>>
>>>> The difference from the original (rev01) proposal is below:
>>>> 1. We remove 'duplicity', 'google-authenticator', 'pam-shield' and 
>>>> 'suricata' in the
>>>new proposal because they have an issue such as non-well maintained, 
>>>python version, too much dependencies and so on. We'll separately 
>>>propose them after solved these issues.
>>>> 2. The new proposal shows all source package as flat. Thanks to the 
>>>> new script,
>>>Kazu!
>>>> 3. Actually several packages overlap with the proposed packages for 
>>>> minimum
>>>base system in Debian, so I added comment them like that.
>>>>
>>>> @kazuhiro3.hayashi at toshiba.co.jp,
>>>> Would you check this proposal and set the due date to review it?
>>>>
>>>> Please reply if you have any comments or questions.
>>>
>>>I have a comment about packages in the proposal that depend on 
>>>hardware / system features -
>>>
>>>* Some packages in the proposal depend on special purpose hardware to
>>>  provide their functionality. e.g., TPM.
>>>
>>>  In systems, where TPM is not present (or similar functionality is 
>>> provided by alternate mechanisms), the TPM related packages will not 
>>> be useful. e.g., the non-x86 platforms in the CIP reference hardware 
>>> list.
>>>
>>>* Similarly, some packages require the system to be connected to the
>>>  network.
>>>
>>>In both of these situations, I am wondering what is the impact on 
>>>compliance? Is there a need to also define minimal set of hardware 
>>>features expected from reference hardware to be able to meet 
>>>compliance
>requirements?
>>>
>>
>> How each reference hardware satisfies the requirements should be 
>> considered by each reference hardware provider.
>
>Agreed.
>
>But without an explicit statement of the requirement, how can a 
>hardware vendor wanting to develop system for CIP users know what 
>features to enable in their system?
>
>> If we provide hardware mechanisms similar with TPM to protect 
>> credentials and authentications, we can meet compliance requirements.
>
>TPM2 specification is more than 2000 pages long with many features and 
>functions. I believe the IEC standard requires a subset of this 
>functionality. The Security WG maybe intimately familiar with the 
>required features but for the reviewers on this list, there isn't any criteria to use for evaluation.
>
>Stating these functional requirements explicitly will serve the dual 
>purpose of -
>
>* Provide an objective criteria for evaluating the package proposal 
>(and
>  discuss alternatives)
>
>* Give hardware / system vendors the features / functions needed by CIP
>  users.
>
>What do you think?
>
>> TPM related packages are options in only systems where TPM is 
>> implemented as you said. If supporting these packages require too 
>> much costs, the necessity of them will diminish.  Actually the 
>> standard lists TPM as a typical example, so we thought it will be 
>> useful to maintain TPM related packages for many users, but their 
>> necessities depend on supporting cost.
>
>I see - thanks for the background of the TPM-related packages in the proposal.
>
>>
>>>To help review the package list (and also discuss alternatives), it 
>>>would help to define the underlying functionality that is required in 
>>>more detail, e.g., secure key storage, verified boot, etc. It'll make 
>>>it possible review the proposal more concretely.
>
>[...]

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.