On 17.01.20 14:14, email@example.com wrote:
3. Actually several packages overlap with the proposed packages for minimum base system in Debian, so I added commentThank you for taking time to check this...
them like that.
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 :)
The proposal #2 is now proceeding in parallel so it's a bit difficult to decide
Would you check this proposal and set the due date to review it?
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.
Please reply if you have any comments or questions.
From: firstname.lastname@example.org <email@example.com>
Sent: Friday, December 20, 2019 6:59 PM
To: firstname.lastname@example.org; Kento Yoshida <email@example.com>;
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
@firstname.lastname@example.org 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 <email@example.com> On Behalf Of
Sent: Thursday, December 19, 2019 7:48 PM
To: firstname.lastname@example.org; email@example.com
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security
On 09.12.19 14:54, firstname.lastname@example.org 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
cip-dev mailing list
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux