All of lore.kernel.org
 help / color / mirror / Atom feed
From: ben.hutchings@codethink.co.uk (Ben Hutchings)
To: cip-dev@lists.cip-project.org
Subject: [cip-dev] [cip-kernel-sec] failure when importing stable
Date: Fri, 14 Jun 2019 14:00:45 +0100	[thread overview]
Message-ID: <1560517245.21054.27.camel@codethink.co.uk> (raw)
In-Reply-To: <TY2PR01MB3323D92EC6AC8D81D65A51B8D0EE0@TY2PR01MB3323.jpnprd01.prod.outlook.com>

On Fri, 2019-06-14 at 05:01 +0000, daniel.sangorrin at toshiba.co.jp
wrote:
> Hello Ben,
> 
> I am trying to write a Quickstart about "cip-kernel-sec" for the CIP
> wiki (see initial draft attached).
> The Readme file mentions that you need two remote branches (torvalds
> and stable) defined on the ../kernel directory by default. However,
> that didn't seem enough because conf/remotes.yml also includes a
> remote branch "cip".

So the README should refer to that file rather than repeating a list of
remotes.

> I added a "cip" remote branch, but then I got an error when importing
> (see draft). Could you help me understand why do I need the CIP
> remote branch if ../kernel already has the CIP information? It seems
> I am doing something wrong.

import_stable.py doesn't update the "torvalds" remote, and neither did
you, so you don't have all the expected tags.

I suppose that import_stable.py should do that.

> I am still trying to figure out the correct workflow. I have thought
> of at least two use cases:
> 
> 1) CIP kernel maintainer: (s)he wants to know whether there are
> debian/ubuntu CVEs pending on his branch.
> $ ./scripts/report_affected.py linux-4.4.y
> 
> 2) Product engineer: he wants to know which CVEs are pending on the
> kernel since he shipped the device. If the CVEs are critical he may
> decide to create a new release and update the device.?
> $ ./scripts/report_affected.py linux-4.4.y:v4.4.176-cip31<-- is
> something like this possible?

Not yet but it would probably not be hard to do.

> Also, I wanted to know how new issues are added. I am guessing
> something like this:
> 
> $ ./scripts/import_debian.py
> ? -> automatically adds yml files in issues/
> $ ./scripts/validate.py
> ? -> checks all yml syntax

You don't need to run validate.py immediately after an import, unless
you suspect a bug in the importer.  It's only important after hand-
editing.

> $ vi issues/CVE-xxx <-- edit by hand those with syntax errors, or
> other errors?

You would edit by hand if you see that some imported information is
incorrect or there is missing information.

> $ ./scripts/validate.py <-- repeat validate until no errors appear
> $ ./scripts/cleanup.py <-- correct indentation or spaces?

YAML allows the same thing to be written in different ways, e.g.
bracketed vs bulleted lists.  The purpose of cleanup.py is to make the
syntax and ordering of items consistent with the importers, to reduce
"noise" in diffs.

Ben.

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

  reply	other threads:[~2019-06-14 13:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-14  5:01 [cip-dev] [cip-kernel-sec] failure when importing stable daniel.sangorrin at toshiba.co.jp
2019-06-14 13:00 ` Ben Hutchings [this message]
2019-06-17  5:23   ` daniel.sangorrin at toshiba.co.jp

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=1560517245.21054.27.camel@codethink.co.uk \
    --to=ben.hutchings@codethink.co.uk \
    --cc=cip-dev@lists.cip-project.org \
    /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.