[cip-dev][isar-cip-core] version management

[cip-dev][isar-cip-core] version management

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Hello Dinesh, Jan, all

Dinesh raised an important issue on another thread. I created a new thread to discuss about it.

> From: Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
[...]
> I have a question, while planning this activity can we define some version for CIP Core itself? As currently we have
> CIP Kernel versions and versions for individual application packages.
> e.g. If we want to share CIP Kernel and CIP Core version for IEC assessment we lack CIP Core version.
> May be we can discuss it in upcoming CIP Core meeting.

I agree that we need to version our releases. In Debian there are point versions, but I don't think we need to follow that. Maybe we can just use a number such as the date of the release (eg. 20200519 <-- yearmonthday).

Some questions regarding versioning:
   * should we also store metadata associated with a release?
	* a package list manifest for each release (dpkg -l)?
        * the cip-core branch and commit
        * the cip-kernel branch and commit
        * md5sum of the image
   * do we need repository management infrastructure?
       * mirror part of the debian repository (only the packages that we need)
       * create snapshots for each release including the source code packages

Storing metadata should not be too difficult, just add some script code to gitlab-ci.

Keeping snapshots would require much more work and resources. I think this is not necessary since we are not going to rebuild images, and if we wanted we could do it somehow from the package list manifest and the upstream Debian ftp servers.

Thanks,
Daniel


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4632): https://lists.cip-project.org/g/cip-dev/message/4632
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2496 bytes --]

On 19.05.20 05:11, daniel.sangorrin@toshiba.co.jp wrote:
> Hello Dinesh, Jan, all
> 
> Dinesh raised an important issue on another thread. I created a new thread to discuss about it.
> 
>> From: Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
> [...]
>> I have a question, while planning this activity can we define some version for CIP Core itself? As currently we have
>> CIP Kernel versions and versions for individual application packages.
>> e.g. If we want to share CIP Kernel and CIP Core version for IEC assessment we lack CIP Core version.
>> May be we can discuss it in upcoming CIP Core meeting.
> 
> I agree that we need to version our releases. In Debian there are point versions, but I don't think we need to follow that. Maybe we can just use a number such as the date of the release (eg. 20200519 <-- yearmonthday).

Or the more common pattern "2020.05".

How often should we release? What would be the required quality criteria?

> 
> Some questions regarding versioning:
>     * should we also store metadata associated with a release?
> 	* a package list manifest for each release (dpkg -l)?
>          * the cip-core branch and commit
>          * the cip-kernel branch and commit
>          * md5sum of the image

When using a meta layer for generating the image - like isar-cip-core -, 
almost everything is described that way already, except for...

>     * do we need repository management infrastructure?
>         * mirror part of the debian repository (only the packages that we need)
>         * create snapshots for each release including the source code packages
> 

...the binary packages. So the second piece would be a versioned repo 
for those.

That can be snapshot.debian.org, like we do in [1][2], but that this not 
a very reliable source (took me hours recently to rebuild [1] from 
there, you want a better mirror).

> Storing metadata should not be too difficult, just add some script code to gitlab-ci.
> 
> Keeping snapshots would require much more work and resources. I think this is not necessary since we are not going to rebuild images, and if we wanted we could do it somehow from the package list manifest and the upstream Debian ftp servers.

The repo is required if we want to be serious regarding releases.

Jan

[1] https://github.com/siemens/meta-iot2050
[2] 
https://github.com/siemens/meta-iot2050/blob/master/conf/distro/debian-snapshot.list

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

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4633): https://lists.cip-project.org/g/cip-dev/message/4633
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 2612 bytes --]

Hi Jan,

Thanks for your comments. Please check mine inline

> From: Jan Kiszka <jan.kiszka@siemens.com>
> > I agree that we need to version our releases. In Debian there are point versions, but I don't think we need to follow
> that. Maybe we can just use a number such as the date of the release (eg. 20200519 <-- yearmonthday).
> 
> Or the more common pattern "2020.05".
> 
> How often should we release? What would be the required quality criteria?

Perhaps one option is to release at the same time the CIP kernel is released, that is every few weeks
https://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git/refs/tags
We can start with "no regressions" as the most basic quality criteria.

> > Some questions regarding versioning:
> >     * should we also store metadata associated with a release?
> > 	* a package list manifest for each release (dpkg -l)?
> >          * the cip-core branch and commit
> >          * the cip-kernel branch and commit
> >          * md5sum of the image
> 
> When using a meta layer for generating the image - like isar-cip-core -,
> almost everything is described that way already, except for...
> 
> >     * do we need repository management infrastructure?
> >         * mirror part of the debian repository (only the packages that we need)
> >         * create snapshots for each release including the source code packages
> >
> 
> ...the binary packages. So the second piece would be a versioned repo
> for those.
> 
> That can be snapshot.debian.org, like we do in [1][2], but that this not
> a very reliable source (took me hours recently to rebuild [1] from
> there, you want a better mirror).
> 
> > Storing metadata should not be too difficult, just add some script code to gitlab-ci.
> >
> > Keeping snapshots would require much more work and resources. I think this is not necessary since we are not going
> to rebuild images, and if we wanted we could do it somehow from the package list manifest and the upstream Debian
> ftp servers.
> 
> The repo is required if we want to be serious regarding releases.

OK, in that case we would need to setup an AWS instance with enough storage ( 1 or more Terabytes), and httpd server, and a repository mirror/snapshot management tool such as [aptly]( https://www.aptly.info/).

Thanks,
Daniel

> 
> Jan
> 
> [1] https://github.com/siemens/meta-iot2050
> [2]
> https://github.com/siemens/meta-iot2050/blob/master/conf/distro/debian-snapshot.list
> 
> --
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE
> Corporate Competence Center Embedded Linux

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4634): https://lists.cip-project.org/g/cip-dev/message/4634
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]

On Tue, 2020-05-19 at 03:11 +0000, Daniel Sangorrin wrote:
> Hello Dinesh, Jan, all
> 
> Dinesh raised an important issue on another thread. I created a new thread to discuss about it.
> 
> > From: Dinesh Kumar <Dinesh.Kumar@TOSHIBA-TSIP.COM>
> [...]
> > I have a question, while planning this activity can we define some version for CIP Core itself? As currently we have
> > CIP Kernel versions and versions for individual application packages.
> > e.g. If we want to share CIP Kernel and CIP Core version for IEC assessment we lack CIP Core version.
> > May be we can discuss it in upcoming CIP Core meeting.
> 
> I agree that we need to version our releases. In Debian there are
> point versions, but I don't think we need to follow that. Maybe we
> can just use a number such as the date of the release (eg. 20200519
> <-- yearmonthday).

Including punctuation in the date may make it more readable.  Also the
day-of-month could be omitted if there will be no more than one release
per month.

> Some questions regarding versioning:
>    * should we also store metadata associated with a release?
> 	* a package list manifest for each release (dpkg -l)?
>         * the cip-core branch and commit
>         * the cip-kernel branch and commit
>         * md5sum of the image

An md5sum would help to detect accidental corruption, but that's all. 
Any release needs to be cryptographically signed, and that will provide
a much stronger integrity check.

>    * do we need repository management infrastructure?
>        * mirror part of the debian repository (only the packages that we need)
>        * create snapshots for each release including the source code packages
> 
> Storing metadata should not be too difficult, just add some script
> code to gitlab-ci.
> 
> Keeping snapshots would require much more work and resources. I think
> this is not necessary since we are not going to rebuild images, and
> if we wanted we could do it somehow from the package list manifest
> and the upstream Debian ftp servers.

We should certainly record all the inputs for an image; that's a
requirement for reproducible builds.  Ideally this record would be
sufficient for someone to repeat the image build in an automated way,
either straight away or at any point in the future.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4639): https://lists.cip-project.org/g/cip-dev/message/4639
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 2746 bytes --]

Thanks for your comments Ben.

> From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Ben Hutchings
> > I agree that we need to version our releases. In Debian there are
> > point versions, but I don't think we need to follow that. Maybe we
> > can just use a number such as the date of the release (eg. 20200519
> > <-- yearmonthday).
> 
> Including punctuation in the date may make it more readable.  Also the
> day-of-month could be omitted if there will be no more than one release
> per month.

My preference was including the day-of-month because
a) the kernel sometimes gets released in less than a month. But that's in case we release at the same pace.
b) if we release a version that has a problem, we can release a new one quickly the next day.

> > Some questions regarding versioning:
> >    * should we also store metadata associated with a release?
> > 	* a package list manifest for each release (dpkg -l)?
> >         * the cip-core branch and commit
> >         * the cip-kernel branch and commit
> >         * md5sum of the image
> 
> An md5sum would help to detect accidental corruption, but that's all.
> Any release needs to be cryptographically signed, and that will provide
> a much stronger integrity check.

Good point, thank you.

We can create a PGP signature on gitlab-ci and send it to S3 together with the OS image. Should we put the public key (and fingerprint) on the image release wiki?

Chris: this could be useful to make sure that we run the right thing in LAVA.

> >    * do we need repository management infrastructure?
> >        * mirror part of the debian repository (only the packages that we need)
> >        * create snapshots for each release including the source code packages
> >
> > Storing metadata should not be too difficult, just add some script
> > code to gitlab-ci.
> >
> > Keeping snapshots would require much more work and resources. I think
> > this is not necessary since we are not going to rebuild images, and
> > if we wanted we could do it somehow from the package list manifest
> > and the upstream Debian ftp servers.
> 
> We should certainly record all the inputs for an image; that's a
> requirement for reproducible builds.  Ideally this record would be
> sufficient for someone to repeat the image build in an automated way,
> either straight away or at any point in the future.

True. I guess we will have to do it properly ;)

Thanks,
Daniel

> 
> Ben.
> 
> --
> Ben Hutchings, Software Developer                         Codethink Ltd
> https://www.codethink.co.uk/                 Dale House, 35 Dale Street
>                                      Manchester, M1 2HF, United Kingdom


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4641): https://lists.cip-project.org/g/cip-dev/message/4641
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]

On Mon, 2020-05-25 at 14:50 +0000, daniel.sangorrin@toshiba.co.jp wrote:
> Thanks for your comments Ben.
> 
> > From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On Behalf Of Ben Hutchings
> > > I agree that we need to version our releases. In Debian there are
> > > point versions, but I don't think we need to follow that. Maybe we
> > > can just use a number such as the date of the release (eg. 20200519
> > > <-- yearmonthday).
> > 
> > Including punctuation in the date may make it more readable.  Also the
> > day-of-month could be omitted if there will be no more than one release
> > per month.
> 
> My preference was including the day-of-month because
> a) the kernel sometimes gets released in less than a month. But that's in case we release at the same pace.
> b) if we release a version that has a problem, we can release a new one quickly the next day.

OK.

> > > Some questions regarding versioning:
> > >    * should we also store metadata associated with a release?
> > > 	* a package list manifest for each release (dpkg -l)?
> > >         * the cip-core branch and commit
> > >         * the cip-kernel branch and commit
> > >         * md5sum of the image
> > 
> > An md5sum would help to detect accidental corruption, but that's all.
> > Any release needs to be cryptographically signed, and that will provide
> > a much stronger integrity check.
> 
> Good point, thank you.
> 
> We can create a PGP signature on gitlab-ci

Possibly... but then:

1. You have to make sure that builds are only signed when the source is
from a tag signed by one of a defined set of trusted keys.
2. You have to somehow keep the signing key secret, while the CI
configuration is mostly public.
3. I would be wary of putting that much trust in shared infrastructure.

> and send it to S3 together with the OS image. Should we put the
> public key (and fingerprint) on the image release wiki?
[...]

I certainly wouldn't feel confident about a public key fingerprint on a
wiki.  It should be somewhere that is clearly official and difficult
for an unauthorised person to change.

Ben.

-- 
Ben Hutchings, Software Developer                         Codethink Ltd
https://www.codethink.co.uk/                 Dale House, 35 Dale Street
                                     Manchester, M1 2HF, United Kingdom


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4642): https://lists.cip-project.org/g/cip-dev/message/4642
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Chris Paterson]

[-- Attachment #1: Type: text/plain, Size: 3149 bytes --]

Hello,

> From: daniel.sangorrin@toshiba.co.jp <daniel.sangorrin@toshiba.co.jp>
> Sent: 25 May 2020 15:51
> 
> Thanks for your comments Ben.
> 
> > From: cip-dev@lists.cip-project.org <cip-dev@lists.cip-project.org> On
> Behalf Of Ben Hutchings
> > > I agree that we need to version our releases. In Debian there are
> > > point versions, but I don't think we need to follow that. Maybe we
> > > can just use a number such as the date of the release (eg. 20200519
> > > <-- yearmonthday).
> >
> > Including punctuation in the date may make it more readable.  Also the
> > day-of-month could be omitted if there will be no more than one release
> > per month.
> 
> My preference was including the day-of-month because
> a) the kernel sometimes gets released in less than a month. But that's in case
> we release at the same pace.
> b) if we release a version that has a problem, we can release a new one
> quickly the next day.
> 
> > > Some questions regarding versioning:
> > >    * should we also store metadata associated with a release?
> > > 	* a package list manifest for each release (dpkg -l)?
> > >         * the cip-core branch and commit
> > >         * the cip-kernel branch and commit
> > >         * md5sum of the image
> >
> > An md5sum would help to detect accidental corruption, but that's all.
> > Any release needs to be cryptographically signed, and that will provide
> > a much stronger integrity check.
> 
> Good point, thank you.
> 
> We can create a PGP signature on gitlab-ci and send it to S3 together with the
> OS image. Should we put the public key (and fingerprint) on the image
> release wiki?
> 
> Chris: this could be useful to make sure that we run the right thing in LAVA.

It's an idea, I'm not sure it's something that LAVA currently supports though.
No reason why support couldn't be added.

Kind regards, Chris

> 
> > >    * do we need repository management infrastructure?
> > >        * mirror part of the debian repository (only the packages that we
> need)
> > >        * create snapshots for each release including the source code
> packages
> > >
> > > Storing metadata should not be too difficult, just add some script
> > > code to gitlab-ci.
> > >
> > > Keeping snapshots would require much more work and resources. I think
> > > this is not necessary since we are not going to rebuild images, and
> > > if we wanted we could do it somehow from the package list manifest
> > > and the upstream Debian ftp servers.
> >
> > We should certainly record all the inputs for an image; that's a
> > requirement for reproducible builds.  Ideally this record would be
> > sufficient for someone to repeat the image build in an automated way,
> > either straight away or at any point in the future.
> 
> True. I guess we will have to do it properly ;)
> 
> Thanks,
> Daniel
> 
> >
> > Ben.
> >
> > --
> > Ben Hutchings, Software Developer                         Codethink Ltd
> > https://www.codethink.co.uk/                 Dale House, 35 Dale Street
> >                                      Manchester, M1 2HF, United Kingdom


[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4643): https://lists.cip-project.org/g/cip-dev/message/4643
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [cip-dev][isar-cip-core] version management

[Daniel Sangorrin]

[-- Attachment #1: Type: text/plain, Size: 2231 bytes --]

Hello Ben,

Thanks a lot for your comments.

> From: Ben Hutchings <ben.hutchings@codethink.co.uk>
> > We can create a PGP signature on gitlab-ci
> 
> Possibly... but then:
> 
> 1. You have to make sure that builds are only signed when the source is
> from a tag signed by one of a defined set of trusted keys.

We could check that automatically, but we would still need some secret environment variables on the build container to do so.

> 2. You have to somehow keep the signing key secret, while the CI
> configuration is mostly public.
> 3. I would be wary of putting that much trust in shared infrastructure.

My idea here was to use gitlab-ci custom environment variables, which can only be seen by the owner of the repository and the build container instance (as an environment variable). Note that we are using our own kubernetes server (not the gitlab-ci shared runners).

If we assume that an attacker is able to access the gitlab-ci custom environment variables settings (eg: they stole the repository owner user, password and hacked their double factor authentication), we need to assume he is able to change the git repository, the gitlab-ci yml scripts, access kubernetes, and access part of our AWS storage as well.

> > and send it to S3 together with the OS image. Should we put the
> > public key (and fingerprint) on the image release wiki?
> [...]
> 
> I certainly wouldn't feel confident about a public key fingerprint on a
> wiki.  It should be somewhere that is clearly official and difficult
> for an unauthorised person to change.

I meant the gitlab-ci wiki here, but yeah that could be the CIP project website as well. I was just wondering if we would need to put it on a key server or showing it on a website would be enough for our purposes. In the end we need to balance usability as well.
Of course, hackers with motivation could probably hack our website.

In the end, here we want to release images for new users to try the CIP software on the supported reference hardware. We could suggest them to do so in an isolated LAN environment just in case. And for developers/power users, they could just build and customize the images by themshelves.

Thanks,
Daniel

[-- Attachment #2: Type: text/plain, Size: 419 bytes --]

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#4651): https://lists.cip-project.org/g/cip-dev/message/4651
Mute This Topic: https://lists.cip-project.org/mt/74318282/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy  [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-