Hi Pavel,

Happy new year to you all!

Just a quick update to go through the latest status and some recent changes to the CIP testing for the Linux Kernel.

# LAVA Labs
We currently have two LAVA labs, lab-cip-renesas and lab-cip-mentor. In total we now host 10 devices plus 2 qemu machines.
See [1] for details.

[1] https://lava.ciplatform.org/scheduler/alldevices


# Continuous Integration
## GitLab CI configuration
CI configuration (specified in .gitlab-ci.yml files) has (mostly) been moved out of the CIP Kernel branches and into a new repository called cip-linux-pipelines [2].
This means that changes can be easily made without getting in the way of the Kernel source maintenance. It also means that there won't be any merge problems for the different branches (e.g. -rt).

[2] https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/


## stable-rc builds
We are now actively testing stable release candidates for the linux-4.19.y and linux-4.4.y Linux kernels.
Two repositories have been created to manage CI testing of Greg's stable-rc releases.
linux-stable-rc [3] is a simple mirror of Greg's linux-stable-rc repository [4] on kernel.org. However, I've added some webhooks that trigger CI jobs in the linux-stable-rc-ci repository [5], which is where we can view the actual build and test jobs.
As part of the above process, commits are created that mimic the latest commit on the linux-4.[19|4].y branches so that it's clear what has been tested (there is no longer a need to look through the build logs). See [6] for an example of what it looks like.
Any issues are (manually) reported to the linux-stable mailing list.

[3] https://gitlab.com/cip-project/cip-testing/linux-stable-rc/
[4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
[5] https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/
[6] https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/commits/linux-4.19.y


## Testing
We now support boot, smc (spectre/meltdown checker) and ltp (Linux Test Project) test cases. (See [7]).
Boot and smc tests are run on every push to the linux-4.[19|4].y-cip branches. LTP tests are run on "release candidates" (see [8]).
Currently the LTP tests are only being run on the Renesas platforms, but hopefully this will change soon.

[7] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/cioverview#tests
[8] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/releasecandidatetesting


## Configurations
The DE0-Nano-SoC and SIMATIC IPC227E boards are now being built for and tested with the CIP branches.
See [9] for an up to date list of all of the configurations that are now built, and what they are tested with.

[9] https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/cioverview#cip_kernel_configurations


# Documentation
Various pages have been updated on the CI Wiki. Some listed below:
* CIP Testing working group: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/ciptestingwg
* CIP Centralised Testing: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting
* Continuous Integration overview: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/cioverview
* Release candidate testing: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/centalisedtesting/releasecandidatetesting
* Reference platforms: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware
* RZ/G2M platform/software info: https://wiki.linuxfoundation.org/civilinfrastructureplatform/ciptesting/cipreferencehardware/hihope-rzg2m
* Kanban board: https://gitlab.com/cip-project/cip-testing/linux-cip-ci/-/boards


Let me know if you have any queries.

Kind regards, Chris

Hello,

Do you need someone reliable to transcribe both your short term and long term projects? Or do you need an accurate transcript for your audio or video? 

Allow us to transcribe your audio and provide you accurate transcripts and let us help you reach your business/project goals through the help of our transcription services.

What are our goals with each transcript?

• Speed
• Accuracy
• Confidentiality

Each transcript is properly formatted. Strict grammar and punctuation rules are adhered to and of course, file security is something we take very seriously. 

Have any transcription queries? Send me a message. Let's discuss what you need to get done. We will address any concerns you have. 

• Professional transcription
• Accurate and thorough
• Beautifully transcribed documents.
• Grammar, spelling and jargon thoroughly checked

We have transcribed audios & videos under various requirements such as :

• Medical transcription
• Technical
• Academic
• Lectures
• Business
• Groups
• Legal
• Research interviews

more...

Skilled with international accents and prompt response. Our pricing is better or comparable to individual service provider. In addition we also assist in APA Style formatting for research papers. Please note we don’t conduct research but assist only in formatting of the papers.

Regards,
Joseph Gladden

Unsubscribe

Hi!

To prepare -cip-rt-rebase, I'd like to start with -cip-rebase. That
seems to be easy with latest version, but not with the older ones:

pavel@duo:~/cip/k$ git show v4.19.91-cip17-rebase
tag v4.19.91-cip17-rebase
commit 0c809da57d1f66315f0d75cab818cf1121ba652c (tag: v4.19.91-cip17-rebase, origin/linux-4.19.y-cip-rebase)
Author: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@...>
Date: Sat Dec 28 05:55:06 2019 +0900

CIP: Bump version suffix to -cip17 after merge from stable

pavel@duo:~/cip/k$ git show v4.19.88-cip16-rebase
fatal: ambiguous argument 'v4.19.88-cip16-rebase': unknown revision or path not in the working tree.

Is there way to get to that version? Would it be possible to keep
those tags in future?

Thanks,

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Hi,

CIP kernel team has released Linux kernel v4.19.91-cip17.
The linux-4.19.y-cip tree has been updated base version from 4.19.88 to 4.19.91,
and the following features have been backported and updated:
- Support Renesas RZ/G2N SoC (r8a774b1)
- Support HiHope RZ/G2N board

You can get this release via the git tree at:

v4.19.91-cip17:
repository:
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git
branch:
linux-4.19.y-cip
commit:
102c40c39125184e0a72a22d3fa2e395d9deef54

Best regards,
Nobuhiro

Hi all,

Kindly be reminded to attend the weekly meeting through IRC to discuss technical topics with CIP kernel today.

*Please note that the IRC meeting was rescheduled to UTC (GMT) 09:00 starting from the first week of Apr. according to TSC meeting*
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019&month=11&day=28&hour=9&min=0&sec=0&p1=241&p2=137&p3=179&p4=136&p5=37&p6=248

US-West US-East UK DE TW JP
01:00 04:00 09:00 10:00 17:00 18:00

Channel:
* irc:chat.freenode.net:6667/cip

Last week's meeting minutes:
https://irclogs.baserock.org/meetings/cip/2019/12/cip.2019-12-19-09.00.log.html

Agenda:

* Action item
1. Test LTS (pre)releases directly - patersonc
2. Create a way/process to run LTP only for release tests - patersonc
3. Combine rootfilesystem with kselftest binary - Iwamatsu-san
4. Document a process on how to add tests to the CIP test setup - patersonc
5. Arrangement of F2F Kernel Meeting in Nurnberg - masashi910
6. Add config for qemux86-64 and BBB to both 4.4 and 4.19 -iwamatsu

* Kernel maintenance updates
* Kernel testing
* CIP Core
* Software update
* AOB
1. IRC meeting next week
I would like to skip an IRC meeting next week. The next IRC meeting should be on January 9th.

The meeting will take 30 min, although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting.

Best regards,
--
M. Kudo
Cybertrust Japan Co., Ltd.

Hi Sir/Madam,

 

Huang Dekai

____________________________

Tianjin Worlds Valve co., ltd.

www.wdsvalve.com

www.worldsvalve.com

Hello Jan, Kent, and all CIP core members,

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

I would like to confirm that the following solution can satisfy our requirements.

Examples:
* proposal*.yml: The package proposal file that a proposer is creating using "generate-proposal.py"
* pkglist_buster.yml: Existing "supported" package list, that was created/updated before
(See the attached files. All information except "bin_pkgs" are dropped to simplify.)

Solution:
0. Use the same YML format as Kent's proposal (Don't change the current YML format)
1. Add a new script "check-deps.py" to check if binary packages in "depends:" are included in
either "proposal.yml" or "pkglist_buster.yml"
2. "generate-proposal.py" runs "check-deps.py" at the end and proposer needs to
add more packages to "proposal.yml" if unmet dependencies are reported by "check-deps.py"
3. The proposer can request the package proposal only if "check-deps.py" reports nothing

In the attached examples, the initial proposal "proposal1.yml" has an unmet dependency (= lsb-base).
"check-deps.py" reports this then the proposer add "lsb-base" source package and binary package
to the second proposal "proposal2.yml", which satisfies all run-time dependencies
so can be proposed to cip-dev.

What do you think?
If OK, we will update the scripts in https://gitlab.com/cip-project/cip-core/cip-pkglist
based on the above solution.

Best regards,
Kazu

Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... 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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

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

Hi,

Hello Jan and CIP core members,

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... 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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

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

Hello Chris,

Hello Hayashi-san,

From: cip-dev <cip-dev-bounces@...> On Behalf Of
kazuhiro3.hayashi@...
Sent: 19 December 2019 11:48

Hello,

In the latest CI for cip-core/deby/cip-core-buster,
I got the following error (and warnings), probably related to kas/docker-
entrypoint.

$ /kas/docker-entrypoint
useradd: user 'builder' already exists
error: failed switching to "builder": operation not permitted

I've submitted a MR that fixes this issue:
https://gitlab.com/cip-project/cip-core/deby/merge_requests/3

Thank you very much!
I've merged the MR and confirmed that kas build started successfully :)

Note that there is still a build failure as it seems that one of the packages the build tries to download is no longer
available:
http://ftp.debian.org/debian/pool/main/b/base-files/base-files_10.3+deb10u1.dsc

I've fixed this by updating the metadata of poky+meta-debian to the latest revisions.
https://gitlab.com/cip-project/cip-core/deby/pipelines/104918124
Thank you for informing this.

Best regards,
Kazu

Kind regards, Chris

Example of the failure (the latest):
https://gitlab.com/cip-project/cip-core/deby/-/jobs/384499394

Example of the success (1 month ago):
https://gitlab.com/cip-project/cip-core/deby/-/jobs/333094418

Do anyone know related changes which happen recently?

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

Hello Hayashi-san,

From: cip-dev <cip-dev-bounces@...> On Behalf Of
kazuhiro3.hayashi@...
Sent: 19 December 2019 11:48

Hello,

In the latest CI for cip-core/deby/cip-core-buster,
I got the following error (and warnings), probably related to kas/docker-
entrypoint.

$ /kas/docker-entrypoint
useradd: user 'builder' already exists
error: failed switching to "builder": operation not permitted

I've submitted a MR that fixes this issue:
https://gitlab.com/cip-project/cip-core/deby/merge_requests/3

Note that there is still a build failure as it seems that one of the packages the build tries to download is no longer available:
http://ftp.debian.org/debian/pool/main/b/base-files/base-files_10.3+deb10u1.dsc

Kind regards, Chris

Example of the failure (the latest):
https://gitlab.com/cip-project/cip-core/deby/-/jobs/384499394

Example of the success (1 month ago):
https://gitlab.com/cip-project/cip-core/deby/-/jobs/333094418

Do anyone know related changes which happen recently?

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

Hi all,

On 20.12.19 10:58, kazuhiro3.hayashi@... 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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

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

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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

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

Hi!

This patch series add DU support for iWave iwg20d platform based on RZ/G1N.

This patch series is based on linux-4.4.y-cip and all the patches in this
series are cherry-picked from upstream.

Biju Das (3):
dt-bindings: display: renesas: du: Document the r8a7744 bindings
drm: rcar-du: Add R8A7744 support
ARM: dts: r8a7744: Add DU support

Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++
arch/arm/boot/dts/r8a7744.dtsi | 10
+++++++++-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
3 files changed, 13 insertions(+), 2 deletions(-)

Looks good to me these patches.
If other reviewer have no opinion, I will apply this series.

Looks good to me, too. Go ahead :-).
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)
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 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

From: cip-dev <cip-dev-bounces@...> 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@... 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@...> On Behalf Of Jan Kiszka
Sent: Thursday, December 19, 2019 7:48 PM
To: kazuhiro3.hayashi@...; cip-dev@...
Subject: Re: [cip-dev] [cip-core] Package Proposal #1 (Security packages)

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 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@...
https://lists.cip-project.org/mailman/listinfo/cip-dev
_______________________________________________
cip-dev mailing list
cip-dev@...
https://lists.cip-project.org/mailman/listinfo/cip-dev