toggle quoted messageShow quoted text
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.
Would you check this proposal and set the due date to review it?
Please reply if you have any comments or questions.
From: kazuhiro3.hayashi@... <kazuhiro3.hayashi@...>
Sent: Friday, December 20, 2019 6:59 PM
To: jan.kiszka@...; Kento Yoshida <kento.yoshida.wz@...>;
Subject: RE: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
On 20.12.19 03:25, Kento Yoshida wrote:client functionality.
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
fundamental projects, I think "chrony"
The reason we want to add Chrony to our core packages is to supportby CII as being a superior secure NTP implementation.
various use cases, and because Chrony is recognized
Since the CII aims to invest in core infrastructure, providing funding for
would be more secure and sustainable.them flat?
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:I'm missing the new dependencies in the top-list. Didn't we agree on listing
We need to reconsider the format of proposal.yml (and scripts as well).
our list already?
This, e.g., pulls python, currently even v2 - anything but a
trivial package. Or did I miss that we have this in
@kazuhiro3.hayashi@... and @Dinesh Kumar, Do you need a
script modification to address this issue?
It seems not to be reviewed enough.
dependencies package displayed in this proposal.
Actually, proposals for run-time dependencies package of top-listsin the security working group.
are still in preparation and are under investigation
The automatic outputs of the script have been used as it is for the
I'm assuming the "existing package set" is the list of packages that are already
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.
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,
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
I only checkedYes, we need to share the concrete examples of packages, PDP steps, and the
suricata because of the outstanding python dependency, but there might
be more issue. This needs to be checked carefully again.
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
From: cip-dev <cip-dev-bounces@...> On Behalf Of
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
On 09.12.19 14:54, kazuhiro3.hayashi@... wrote:
Hello CIP Core members,
I would like to start the "review" phase (Phase 2) of the attached package
The packages are proposed by CIP security WG to satisfy their required
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:Why still chrony, why not simply systemd timers? Legacy?
reason: For supporting IEC-62443-4-2 certification for CR 2.11, 2.11(1)
security_criteria: network::server, network::service
suricata:I'm missing the new dependencies in the top-list. Didn't we agree on
listing them flat? This, e.g., pulls python,
v2 - anything but a trivial package. Or did I miss that we have this in our list
Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate
Competence Center Embedded Linux