All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel Sangorrin" <daniel.sangorrin@toshiba.co.jp>
To: <ben.hutchings@codethink.co.uk>, <Chris.Paterson2@renesas.com>
Cc: <cip-dev@lists.cip-project.org>, <dinesh.kumar@toshiba-tsip.com>,
	<jan.kiszka@siemens.com>
Subject: Re: [cip-dev][isar-cip-core] version management
Date: Thu, 28 May 2020 03:28:02 +0000	[thread overview]
Message-ID: <OSBPR01MB20535801BA206E07A299F805D08E0@OSBPR01MB2053.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <1d9dc0f0e1d9689eb7b6578127e93f2907c54b17.camel@codethink.co.uk>

[-- 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]
-=-=-=-=-=-=-=-=-=-=-=-

  reply	other threads:[~2020-05-28  3:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19  3:11 [cip-dev][isar-cip-core] version management Daniel Sangorrin
2020-05-19  5:19 ` Jan Kiszka
2020-05-19 10:55   ` Daniel Sangorrin
2020-05-22 13:04 ` Ben Hutchings
2020-05-25 14:50   ` Daniel Sangorrin
2020-05-26 11:42     ` Ben Hutchings
2020-05-28  3:28       ` Daniel Sangorrin [this message]
2020-05-26 13:25     ` Chris Paterson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OSBPR01MB20535801BA206E07A299F805D08E0@OSBPR01MB2053.jpnprd01.prod.outlook.com \
    --to=daniel.sangorrin@toshiba.co.jp \
    --cc=Chris.Paterson2@renesas.com \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=cip-dev@lists.cip-project.org \
    --cc=dinesh.kumar@toshiba-tsip.com \
    --cc=jan.kiszka@siemens.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.