Date   

[Git][cip-project/cip-kernel/cip-kernel-sec][master] 3 commits: Import data from stable

Agustin Benito Bethencourt
 

Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

Commits:

  • 8c40df68
    by Ben Hutchings at 2018-11-22T19:41:46Z
    Import data from stable
    
  • 3da94bb0
    by Ben Hutchings at 2018-11-22T20:10:29Z
    webview: Abbreviate link text for references
    
    We don't have any description of what each reference is specifically
    about, so currently we use the URL as the link text.  This can be
    quite hard to read.
    
    Generally the most significant parts of the URL are at the beginning
    (hostname) and end (query part or last path part).  Add a "urlabbrev"
    filter that drops the scheme and replaces any other insignificant
    part with an ellipsis.  Use it in the issue template.
    
  • cfd826db
    by Ben Hutchings at 2018-11-30T18:43:37Z
    Fill in and correct commit lists for various issues
    

8 changed files:

Changes:

  • issues/CVE-2017-18261.yml
    ... ... @@ -15,6 +15,6 @@ comments:
    15 15
         "arm64: arch_timer: Allows a CPU-specific erratum to only affect a
    
    16 16
         subset of CPUs".
    
    17 17
     introduced-by:
    
    18
    -  mainline: [96b3d28bf4b00f62fc8386ff5d487d1830793a3d]
    
    18
    +  mainline: [6acc71ccac7187fc0ef85f10bd09c2058f21fab5]
    
    19 19
     fixed-by:
    
    20 20
       mainline: [adb4f11e0a8f4e29900adb2b7af28b6bbd5c1fa4]

  • issues/CVE-2018-1094.yml
    ... ... @@ -20,6 +20,8 @@ comments:
    20 20
         but the issue reported for CVE-2018-1094 does not apply to 4.9.
    
    21 21
     reporters:
    
    22 22
     - Wen Xu
    
    23
    +introduced-by:
    
    24
    +  mainline: [dec214d00e0d78a08b947d7dccdfdb84407a9f4d]
    
    23 25
     fixed-by:
    
    24 26
       linux-4.14.y: [26dbb30c58ffb85bc015bd5e58831483d50f7d18]
    
    25 27
       linux-4.16.y: [114c42aaa63152d31d3c18d5b750de9560f38a63]
    

  • issues/CVE-2018-1128.yml
    ... ... @@ -14,3 +14,8 @@ fixed-by:
    14 14
         6daca13d2e72bedaaacfc08f873114c9307d5aea]
    
    15 15
     ignore:
    
    16 16
       linux-3.16.y: Protocol change is too difficult
    
    17
    +fix-depends-on:
    
    18
    +  0dde584882ade13dc9708d611fbf69b0ae8a9e48: |-
    
    19
    +    Avoids textual conflicts when picking 6daca13d2e72.
    
    20
    +  b3bbd3f2ab19c8ca319003b4b51ce4c4ca74da06: |-
    
    21
    +    Simplifies backporting of 262614c4294d.

  • issues/CVE-2018-18710.yml
    1 1
     description: 'cdrom: fix improper type cast, which can leat to information leak'
    
    2 2
     fixed-by:
    
    3
    +  linux-4.14.y: [a8c254d8e96032d5bb235cb2e777203d9acda09d]
    
    4
    +  linux-4.19.y: [c8099dbf492b565a4f75ae7b8c08b76ca18c4c3f]
    
    5
    +  linux-4.4.y: [661aa0b46dfb23700b569ac319b95e0b0154832f]
    
    6
    +  linux-4.9.y: [8dd745a8799ee01fc67b64fd33cdb44d04eb7e4c]
    
    3 7
       mainline: [e4f3aa2e1e67bb48dfbaaf1cad59013d5a5bc276]

  • issues/CVE-2018-18955.yml
    ... ... @@ -3,3 +3,5 @@ fixed-by:
    3 3
       linux-4.18.y: [bbfed258eb08070e051a1c086282623cc562ff24]
    
    4 4
       linux-4.19.y: [9a7a80fb02cc7515b273dbb4249374d6e6a35b70]
    
    5 5
       mainline: [d2f007dbe7e4c9583eea6eb04d60001e85c6f1bd]
    
    6
    +introduced-by:
    
    7
    +  mainline: [6397fac4915ab3002dc15aae751455da1a852f25]

  • issues/CVE-2018-5391.yml
    ... ... @@ -31,6 +31,21 @@ comments:
    31 31
         The commits backported to 4.9.134 are complete and are not introducing
    
    32 32
         thus CVE-2018-14641.
    
    33 33
     fixed-by:
    
    34
    +  linux-4.14.y: [6093d5abcf5ada86d2bb61bd5154bc144bf5a3aa, 673220d6417de8812b20bfeb4d2f809e05a82463,
    
    35
    +    0cbf74b9519d8f73dd27cc6fad6e03851788f956, 0512f7e93504386cd1223990d9692c20a878d2d9,
    
    36
    +    eb1686ae5e20b4455b80be571e7e41f1c9d7b2ac, 266da0fb83f32e26470017d3eb32cb092b2210ed,
    
    37
    +    11be675bf0aaf4a6dcde817126168b9cbd8ba90e, 33dc9f7c5d127bfc203a17f7a31d4dcc754376df,
    
    38
    +    9aee41eff751e4c789ff785c561d7bf7ad72c286, bd3df633f17d64523828d0ef5d74e4f1a768683c,
    
    39
    +    5b1b3ad46dd100932925e979562aeefaf9ef189e, caa4249eca082c5954ea377aa3ef86b5fc5c1ac1,
    
    40
    +    990204ddc5f67530b2ac616767a5c6937c9fc2af, 085a0147447a4f82138825b6a3a329b997c2fb13,
    
    41
    +    3226bdcb044862084c3bfc3278d148948600ebc4, bd946fb5226e205530bea2581d867642e4b457ed,
    
    42
    +    8291cd943a9b4e2d764a4a294999bbb2f94f153c, 48c2afc16888873da727f9ed7102a620a178fad8,
    
    43
    +    5fff99e88a1f4b4e62fd07bf3eb87305c88f3400, 1c44969111cc68f361638b6e54f5a176609aa05a,
    
    44
    +    7750c414b89bd8204901855bda21c512e269be35, 3bde783eca23d5d3019c220752f5a29083dea27c,
    
    45
    +    5123ffdad65954b3c308e055b388db08987a13ff, 6bf32cda46ebfbaf13da3c48a0a009adae925703,
    
    46
    +    37c7cc80b1d7de36a6ed54796ae30ee091d05eab, 6b921536f1707a240e6f53843f1f26231016fda5,
    
    47
    +    04b28f406e86512a3592664553b5e17efe663ece, c91f27fb571666a176e1446646726f78d4657ddb,
    
    48
    +    b3a0c61b73699b3764a6568e85c67f599158c541, 08fb833b40e361ce927c64d40e348af96996d9eb]
    
    34 49
       linux-4.9.y: [7fca77153c5c2a2c59e70720332bce7088aef8e8, 2ffb1c363dfa89858dded0b291f005faf1b72adc,
    
    35 50
         bbf6d8604475f36279c7b2d9a1f425654bc24588, dae73e7d73fce8d8d5132ec3c94de16280653fc6,
    
    36 51
         1b363f81f38f28bd69ec90837da0f65161f36325, 620018dd713da51daac7ec4cd0ae54b0f0fa0f75,
    

  • scripts/templates/issue.html
    ... ... @@ -14,7 +14,7 @@
    14 14
         <td/>
    
    15 15
         <td>
    
    16 16
           {% for url in issue.references %}
    
    17
    -      <a href="{{ url }}">{{ url }}</a>
    
    17
    +      <a href="{{ url }}">{{ url|urlabbrev }}</a>
    
    18 18
           {% if not loop.last %}|{% endif %}
    
    19 19
           {% endfor %}
    
    20 20
         </td>
    

  • scripts/webview.py
    ... ... @@ -8,6 +8,7 @@
    8 8
     
    
    9 9
     import argparse
    
    10 10
     import os
    
    11
    +import re
    
    11 12
     
    
    12 13
     import cherrypy
    
    13 14
     import jinja2
    
    ... ... @@ -16,9 +17,27 @@ import kernel_sec.branch
    16 17
     import kernel_sec.issue
    
    17 18
     
    
    18 19
     
    
    20
    +# Match host part and either query part or last path part
    
    21
    +_URL_ABBREV_RE = re.compile(
    
    22
    +    r'^https?://([^/]*/?)(?:([^?]*)(\?.*)|(.*?)(/[^/]*/?))$')
    
    23
    +
    
    24
    +
    
    25
    +def _url_abbrev(value):
    
    26
    +    match = _URL_ABBREV_RE.match(value)
    
    27
    +    if not match:
    
    28
    +        return value
    
    29
    +    elif match.group(2) and match.group(3):
    
    30
    +        return match.expand(r'\1…\3')
    
    31
    +    elif match.group(4) and match.group(5):
    
    32
    +        return match.expand(r'\1…\5')
    
    33
    +    else:
    
    34
    +        return match.expand(r'\1\3\5')
    
    35
    +
    
    36
    +
    
    19 37
     _template_env = jinja2.Environment(
    
    20 38
         loader=jinja2.FileSystemLoader('scripts/templates'),
    
    21 39
         autoescape=True)
    
    40
    +_template_env.filters['urlabbrev'] = _url_abbrev
    
    22 41
     
    
    23 42
     
    
    24 43
     class IssueCache:
    


  • Re: Snapshot release of B@D

    Agustín Benito Bethencourt <agustin.benito@...>
     

    Hi,

    On Friday, 30 November 2018 12:03:51 GMT Paul Sherwood wrote:
    Robert
    On 2018-11-30 11:54, Robert Marshall wrote:
    However, from the end of today I shall be leaving codethink and
    retiring!
    I wish CIP well and have appreciated being part of it over the last 2
    years.
    Thank you for all of your contributions over recent years at Codethink-
    it's been a pleasure working with you.

    You will be missed.
    I support Paul words.

    Enjoy your retirement Robert.

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html


    Re: Snapshot release of B@D

    Chris Paterson
     

    Hello Robert,

    From: cip-dev-bounces@... <cip-dev-bounces@...
    project.org> On Behalf Of Robert Marshall
    Sent: 30 November 2018 11:54

    Hi

    The wiki has been updated with a snapshot release of Board at desk
    https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload#snaps
    hot-b-d-box

    the rest of the wiki has been updated to refer to this. The snapshot was
    created in early October. Testing and comments are welcomed!
    Thank you for the update and all your work on B@D.


    However, from the end of today I shall be leaving codethink and retiring!
    I wish CIP well and have appreciated being part of it over the last 2
    years.
    Best of luck for the future! Be sure to check in on CIP now and then :)

    Kind regards, Chris


    Robert (contactible via twitter at @rajm )
    --
    Robert Marshall, Software Developer Codethink Ltd
    Telephone: +44 7762 840 414 3rd Floor, Dale House, 35 Dale Street
    https://www.codethink.co.uk/ MANCHESTER, M1 2HF. United Kingdom
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Re: Snapshot release of B@D

    Paul Sherwood
     

    Robert
    On 2018-11-30 11:54, Robert Marshall wrote:
    However, from the end of today I shall be leaving codethink and retiring!
    I wish CIP well and have appreciated being part of it over the last 2
    years.
    Thank you for all of your contributions over recent years at Codethink- it's been a pleasure working with you.

    You will be missed.


    Snapshot release of B@D

    Robert Marshall <robert.marshall@...>
     

    Hi

    The wiki has been updated with a snapshot release of Board at desk
    https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload#snapshot-b-d-box

    the rest of the wiki has been updated to refer to this. The snapshot was
    created in early October. Testing and comments are welcomed!

    However, from the end of today I shall be leaving codethink and retiring!
    I wish CIP well and have appreciated being part of it over the last 2
    years.

    Robert (contactible via twitter at @rajm )
    --
    Robert Marshall, Software Developer Codethink Ltd
    Telephone: +44 7762 840 414 3rd Floor, Dale House, 35 Dale Street
    https://www.codethink.co.uk/ MANCHESTER, M1 2HF. United Kingdom


    CIP IRC weekly meeting today

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi All,

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

    *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from first week of Nov. according F2F meeting discussion in ELCE.*

    US-West US-East UK DE TW JP
    02:00 05:00 09:00 10:00 17:00 18:00

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

    Agenda:

    * Kernel maintenance updates
    * Kernel testing
    * Software update
    * CIP Core
    * AOB

    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,

    SZ Lin, Moxa.


    Re: [CIP Testing WG] Status update - 26/11/18

    Agustín Benito Bethencourt <agustin.benito@...>
     

    Hi,

    On Tuesday, 27 November 2018 09:59:33 GMT Robert Marshall wrote:
    Thanks Chris for the update!

    Chris Paterson <Chris.Paterson2@...> writes:


    # B@D #

    - Robert has continued to close down issues on GitLab [1] that are either fixed or won’t be fixed in time for his retirement.

    - Now that access to the AWS storage has been restored, the plan is to upload a new version of the B@D ‘box’ [2] that includes all the changes that
    have been done since v1.0 was released.
    As mentioned on the #cip channel the new version is now in place and has
    been tested. Agustín - can I go ahead and update the wiki?
    Sure, go ahead please. Thanks for asking.

    Will we also
    need all the subsidiary packages up there too? Or is it maybe better to discuss
    face to face tomorrow as to what and how the page should look?
    Do not wait. Take a decision and go for it. You have what we did the previous release as example.

    Best Regards

    --
    Agustín Benito Bethencourt
    Principal Consultant
    Codethink Ltd
    We respect your privacy. See https://www.codethink.co.uk/privacy.html


    Re: [CIP Testing WG] Status update - 26/11/18

    Robert Marshall <robert.marshall@...>
     

    Thanks Chris for the update!

    Chris Paterson <Chris.Paterson2@...> writes:


    # B@D #

    - Robert has continued to close down issues on GitLab [1] that are either fixed or won’t be fixed in time for his retirement.

    - Now that access to the AWS storage has been restored, the plan is to upload a new version of the B@D ‘box’ [2] that includes all the changes that
    have been done since v1.0 was released.
    As mentioned on the #cip channel the new version is now in place and has
    been tested. Agustín - can I go ahead and update the wiki? Will we also
    need all the subsidiary packages up there too? Or is it maybe better to discuss
    face to face tomorrow as to what and how the page should look?


    - Daily healthcheck tests for BBB and iwg20m.
    Well nearly daily ;-)

    Robert
    --
    Robert Marshall, Software Developer Codethink Ltd
    Telephone: +44 7762 840 414 3rd Floor, Dale House, 35 Dale Street
    https://www.codethink.co.uk/ MANCHESTER, M1 2HF. United Kingdom


    Re: CIP-dev IRC weekly meeting log: week 46

    Ben Hutchings <ben.hutchings@...>
     

    On Tue, 2018-11-20 at 13:03 +0100, Jan Kiszka wrote:
    Hi Nobuhiro,

    On 19.11.18 23:17, Nobuhiro Iwamatsu wrote:
    Hi,

    2018年11月19日(月) 17:53 Jan Kiszka <jan.kiszka@...>:
    On 19.11.18 09:14, SZ Lin (林上智) wrote:
    Hi,

    Please find the logs of CIP meeting last week in below link:

    https://irclogs.baserock.org/cip/%23cip.2018-11-15.log.html#t2018-11-15T09:00:17

    #action Confirm the next official CIP kernel announcement in TSC meeting.
    #action Make sure armhf is available in Debian 10 (or not)
    https://release.debian.org/buster/arch_qualify.html
    Huh?! Can we support them with hardware to avoid that?
    We can see the current hardware problem of armel / armhf from the following.

    https://lists.debian.org/debian-arm/2018/09/msg00049.html
    Hmm, that message does not yet read to me like a blocker. It's a list of 
    complications, yes.

    I also wonder what makes this buster-specific. The issues with the build 
    environment should be generic, shared with supported arm* for stretch or even older.
    Of course, but including them in buster will add another 2 years to the
    time these architectures have to be supported.

    For what it's worth, the SIGMINSTKSZ issue is fixed in 4.20 by:

    22839869f21a signal: Introduce COMPAT_SIGMINSTKSZ for use in compat_sys_sigaltstack
    24951465cbd2 arm64: compat: Provide definition for COMPAT_SIGMINSTKSZ

    We need to get these added to Debian's 4.19 kernel at least, but they
    might also be candidates for 4.19-stable.

    Ben.

    Again, if there is any concrete thing we could help with here, please let us 
    discuss proposals at TSC level and with Debian folks. armhf is critical for most 
    of us, and that for quite a few years onward.

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


    [CIP Testing WG] Status update - 26/11/18

    Chris Paterson
     

    Hello all,

     

    Some updates from the CIP testing world…

     

    # B@D #

    - Robert has continued to close down issues on GitLab [1] that are either fixed or won’t be fixed in time for his retirement.

    - Now that access to the AWS storage has been restored, the plan is to upload a new version of the B@D ‘box’ [2] that includes all the changes that have been done since v1.0 was released.

    - Daily healthcheck tests for BBB and iwg20m.

     

    # Distributed Testing #

    - We now have access to CIP’s AWS S3 bucket.

    - LAVA master backup scripts tested.

    - LAVA master user accounts created for those requesting one.

    - Daily healthcheck tests for QEMU and iwg20m [3].

     

     

    [1] https://gitlab.com/groups/cip-project/cip-testing/-/issues

    [2] https://wiki.linuxfoundation.org/civilinfrastructureplatform/cipdownload

    [3] https://lava.ciplatform.org/scheduler/labhealth/

     

    Kind regards, Chris


    CIP-dev IRC weekly meeting log: week 47

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi,

    Please find the logs of CIP meeting last week in below link:

    https://irclogs.baserock.org/cip/%23cip.2018-11-22.log.html#t2018-11-22T09:00:05

    SZ Lin, Moxa


    [Git][cip-project/cip-kernel/cip-kernel-sec][master] 12 commits: Extend lists of commits fixing CVE-2018-1128 and CVE-2018-5391

    Agustin Benito Bethencourt
     

    Ben Hutchings pushed to branch master at cip-project / cip-kernel / cip-kernel-sec

    Commits:

    • 7cc54e1f
      by Ben Hutchings at 2018-11-19T16:48:55Z
      Extend lists of commits fixing CVE-2018-1128 and CVE-2018-5391
      
    • 7488998f
      by Ben Hutchings at 2018-11-19T20:01:19Z
      import_stable: Relax matching of upstream commit references in stable
      
      There are 3 different formats currently used in stable branches, in
      descending order of preference:
      
      1. "commit <hash> upstream."
      2. "[ Upstream commit <hash> ]"
      3. "(cherry-picked from commit <hash>)"
      
      There are also a few commits in stable that almost but don't quite
      match this.
      
      Before relaxing the regexes, make sure we only match formats 1 and 2
      on the first non-blank line of the body.  Then:
      
      1. Allow "." or "upstream." to be omitted.
      2. Allow lower-case "upstream".
      3. Allow " " instead of "-".
      
    • b09da59a
      by Ben Hutchings at 2018-11-19T20:01:23Z
      Import more stable commits
      
    • 875e7f49
      by Ben Hutchings at 2018-11-19T20:01:23Z
      Fill in fixes for Meltdown and Spectre variants 1 and 2 on stable branches
      
    • 399f4e9d
      by Ben Hutchings at 2018-11-19T20:36:37Z
      import_stable: Handle cases where some fixes were applied before branch point
      
      If some of the commits needed to fix an issue were applied before
      4.x.y, and some of them were applied on the stable/linux-4.x.y
      branch, we currently don't automatically mark the issue as fixed.
      Teach import_stable to recognise this case.
      
    • de9e94d7
      by Ben Hutchings at 2018-11-19T20:36:40Z
      import_stable: Only update information for live stable branches
      
    • 9c713356
      by Ben Hutchings at 2018-11-19T20:36:58Z
      import_stable: Add debug logging controlled by --debug option
      
      For issues that require a large number of commits to fix, it's tedious
      to work out exactly what's missing from a stable branch (or why
      import_stable.py thinks it's missing).  This adds the option to log
      every decision made by add_backports().
      
    • 34dea904
      by Ben Hutchings at 2018-11-19T20:42:38Z
      import_stable: Handle "never" correctly
      
    • a086e336
      by Ben Hutchings at 2018-11-19T20:50:10Z
      Update status of CVE-2018-3639
      
    • 8acc7d4e
      by Ben Hutchings at 2018-11-22T17:19:04Z
      Update copyright dates for Python sources with significant changes this year
      
    • 63b311c8
      by Ben Hutchings at 2018-11-22T19:37:34Z
      kernel_sec.branch: Change get_live_stable_branches() to fetch live data
      
      Fetch and parse the releases table on the front page of
      www.kernel.org.  Keep a local cache so we don't actually fetch more
      than once a day.  Drop the now unused parameters.
      
    • 2ec5ed1d
      by Ben Hutchings at 2018-11-22T19:38:00Z
      kernel_sec.branch: Delete unused get_stable_branches() function
      
      This was previously used by get_live_stable_branches().
      

    15 changed files:

    Changes:

  • README.md
    ... ... @@ -14,8 +14,8 @@ The schema is roughly documented in
    14 14
     
    
    15 15
     Various scripts, written in Python 3, are in the `scripts`
    
    16 16
     subdirectory.  Supporting modules are in the `kernel_sec` subdirectory
    
    17
    -beneath that.  They require PyYAML (packaged in Debian as
    
    18
    -python3-yaml).
    
    17
    +beneath that.  They require PyYAML and html5lib (packaged in Debian as
    
    18
    +python3-yaml and python3-html5lib).
    
    19 19
     
    
    20 20
     * `scripts/import_debian.py` - import information from Debian's
    
    21 21
     `kernel_sec` project.  It includes all issues that Debian considers
    

  • issues/CVE-2017-17053.yml
    ... ... @@ -11,6 +11,7 @@ references:
    11 11
     - https://github.com/torvalds/linux/commit/ccd5b3235180eef3cfec337df1c8554ab151b5cc
    
    12 12
     - https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.12.10
    
    13 13
     introduced-by:
    
    14
    +  linux-4.4.y: [58ac8c59dbb3a8e8b6414524c2d8f4f0a7bbeaa4]
    
    14 15
       mainline: [39a0526fb3f7d93433d146304278477eb463f8af]
    
    15 16
     fixed-by:
    
    16 17
       linux-4.12.y: [a8da876c1e45b75c082a5dc8ce10c0761a10c638]
    

  • issues/CVE-2017-5715.yml
    ... ... @@ -65,9 +65,104 @@ comments:
    65 65
         marking amd64-microcode as deferred since we don't have updates
    
    66 66
         to ship yet
    
    67 67
       Ubuntu-tyhicks: Variant 2, aka "Spectre"
    
    68
    +  bwh: linux-4.4.y has most fixes but is missing KVM support for IBPB.
    
    68 69
     reporters:
    
    69 70
     - Jann Horn
    
    70 71
     fixed-by:
    
    72
    +  linux-3.16.y: [1b2a12a04fe7233e49dd5601815469bf40fa4749, 84f67d9e273a5512a712a566b6d777a241943838,
    
    73
    +    56e8e5a33f3e6214685da30b556f93b02f26c82d, 15224fb82d3bb0d72bdac57391131e72fade34d3,
    
    74
    +    ae732f0da724f69f81c054c1b2014e2b144f2256, f7c0071623089656c155ab6eb3c7967389415284,
    
    75
    +    6653cade70f3e470cd03793b7a5004f4388b72fc, a4a51323985f7a5de61650c73668f6fb1a87cf39,
    
    76
    +    7163500dfe60dbe67275021f276a4b584737387c, c4ed1bad5316fe67b4c5e0e600a6372e24dff2f4,
    
    77
    +    738e4b6f5719880c4e4ae14899881cafb9ee0373, 6e3008622f5086b6fc819a9588ee67ce374071d0,
    
    78
    +    46d1f87264f6c76befbea9d4a60bfce174439512, 96075314274130d26f617164b2c997e62709ea16,
    
    79
    +    a920aeeee51092d259eae48a22a878554483a446, e09338ed691a7efb05572e68e35dac298d2c8fb3,
    
    80
    +    901d43afc183eeaa38b723bbd5281bf337dc8ef8, bb4875a7f2f2c9339d4041b5662bc029d7c42f28,
    
    81
    +    20e080e2752d108388d386ecc0b33d7797dfb18f, 6653cade70f3e470cd03793b7a5004f4388b72fc,
    
    82
    +    1f8ab11aba17e183e30e45f06227600f76617012, a77a3f23b319797a76c4b4c1f327e55b7665a879,
    
    83
    +    81619a39b447cf0fc5f8dbd46308da4a3ffb90bb, a31751ca36c2d3e1e712aa8e7542669a18d2df4a,
    
    84
    +    9bc82ae19eb4a46dc5792e4b71cdfdfebfa2bbed, c635a741c8c53eee2b68835cdc7b785d4d4a23cb,
    
    85
    +    4b7e6a0ee22df9f46797a7b562825c87f13e08c7, b6912947161a3766d1542a4cc4d1e1ac105e09cc,
    
    86
    +    5ebf8d581c41a7ffc13225b6dbfdd89245f565b4, 13056af0ca8213eb800ada9b2b73eb602bb943e0,
    
    87
    +    3e50ffb9b305fd5c512402d917264a80e0137e8b, dada5d39c32961733d234e2e9e01de83cd05e7c7,
    
    88
    +    221ddea76ecd5dcd2a856228d91ec9ba64caa572, bb01c2fdfcddb23c2ffd733300f6e8e464810b84,
    
    89
    +    36293058920c81bf69fee579f94091264882d34f, 416020e03245a1a60d5de2277149571e8c3d25c4,
    
    90
    +    676520e3ec3a190e5b78c643e740922ab65c4fd7, d3451189b7133f78a9ce335e4bf1f077bc0812ff,
    
    91
    +    eff9612370bef383b4dee621e69f97bf85913626, b6912947161a3766d1542a4cc4d1e1ac105e09cc,
    
    92
    +    09efca6af9ad3ef6ad938f5b124167ea7d39d724, d5f94d8cf3fef111ead1628f99be843004b92dc9,
    
    93
    +    95e1ed3de28edff972f87098d3dfc31779bb8d7c, 7163500dfe60dbe67275021f276a4b584737387c,
    
    94
    +    ead76f4b6ca1e46ae7c8bed05a5b114d05b84de7, 09efca6af9ad3ef6ad938f5b124167ea7d39d724,
    
    95
    +    8869532093454b555338c9f0ca899150c10a72a6, cb4ea8a760444750f9db5e87159d44da9dc786a3,
    
    96
    +    994f527b437995383a9509ef69cd5abf7167b181, bea12e2cac58e4cf5b72d5e435db3a96ba044001,
    
    97
    +    876b732e36a6d19faceeab476937d22615e3d677, bb4875a7f2f2c9339d4041b5662bc029d7c42f28,
    
    98
    +    c51f1e5f57cca88d8d5894b6fad1638f643a99d0, 44491a23b73789c0a914af4ea55ccf8968adf90b,
    
    99
    +    bd1f65872654013615e60530b1ebfa11e0c5799a, 03044aa5a8ecd5e76f3d6b2430314b962ab281fc,
    
    100
    +    bb01c2fdfcddb23c2ffd733300f6e8e464810b84, bea12e2cac58e4cf5b72d5e435db3a96ba044001,
    
    101
    +    44bbffff7dcf26ff181eb5d5cb328e35eef25f34, d48560e9867198b4ad8c609d9ef3f0643355b558,
    
    102
    +    433862605c05695fc2f4ad4fef3036af6735badc]
    
    103
    +  linux-4.14.y: [9298e868dddd820829f814cd25a0f28c92036af7, 5a3e4b399ebc994516f7b6bd8ae0584027e72418,
    
    104
    +    e0d753568c16f123e4805b7136734f3a83403fb6, 649c1de819afc90cb6699dc04f5340009dd3783c,
    
    105
    +    6a4d11820d12836785f64a609eecbcadc0d526d0, 6b95f61a41349ef4a115520ac4868bf52555eab9,
    
    106
    +    3a72bd4b60da338e66922e4f9eded174b3ad147d, dcd4311d0e646ae9e739f7238002b664613f2355,
    
    107
    +    79f2c12856404c5acfbc33e021108c0810a6d2b8, d4edaa981b8749acd8fdd7ab8d2be2585ebeeb9e,
    
    108
    +    82de9301b4ea4389ee889558f770513930bf803f, e0dcc73d67359c67d8b81868c2dd388b0c6be1f2,
    
    109
    +    41f8af6a4656e9dd348506b4ebfa4677730994c3, 470703735b39d743afe0d9e91edaab6ac400c6c7,
    
    110
    +    b0edc2dfb684b43c56d81a58271430a614a4975a, b9cdaaf0a3becc52e8b4662fef28c452c4f009b4,
    
    111
    +    198660b7a5dd33b114001023d540c9072603e2a8, 051547583bdda4b74953053a1034026c56b55c4c,
    
    112
    +    956ec9e7b59a1fb3fd4c9bc8a13a7f7700e9d7d2, 020c755fdb04be9cffa5a30c1624990b7c54cb4c,
    
    113
    +    22371c489842560f99aa6c12a2c00db8b0ecb752, 5fa871644e6d48f5c120e8c469c96850a01c60c8,
    
    114
    +    76bee09efb89b0a71566bec5f36d9e65d9034aef, c927726674c7dfe42e8de585b70ffbd9ec775fc6,
    
    115
    +    86b5b1eb18aa49eedff2c9a9087fc48d03099844, 76c4bd53969bcbaf19fe12218785411b390fd14b,
    
    116
    +    343c91242d092852ab22411780f886317d7001aa, 15ee82be40b6895edeb324435621ef1869aac173,
    
    117
    +    a65710dc584c1c424eb358a1f6e8c01d706e9f81, 0fd222b19766ba28cf6e45b6ad461f1a303831bd,
    
    118
    +    dbbbafce5380f2df32e142e5f08f17cf1b55b59c, b955239cf4ea953eb5fca5409a5524daf20f642a,
    
    119
    +    91ff9a75f360eb89e913fcc4b3a7fbb602c67cbb, 2e9521197f08d8cec826d3a5ff04131e40a79120,
    
    120
    +    92f4b68ed14c7731cadd5bf7501a98da5302c093, 249b1f7a7f09c9c5243f8c592ea7fb13871968bc,
    
    121
    +    7f3e0daa9e125d3d4d7720136370303009edbdeb, a358df03279e806f8f4217eacf813c5b6c3578ee,
    
    122
    +    3e04e09855c5cbc4f18c2d14bec326b1ff6f11f6, 74ae346691dd34d49a5e733af40ca25a4dd42245,
    
    123
    +    c962dfa4aca010e05730ff458210b04c4eb9af14, 85543d7613c481392d564a4956850591b2025f5d,
    
    124
    +    7a3f12294da45e779b313b33077f04b87782985b, ad368e5b2d56ed059ebc8343cd7e713f3a7717d4,
    
    125
    +    7f8da2c8a191f274600bafcf6e58f54e16d5c8de, ebaf2271a024a7000dc83e061349f7bbf2b44281,
    
    126
    +    4c8298c1fdd3317658a3dcd055b19a4c60df947d, d395d69de67ea95760e1f207eb0f6fdfbcb6e069,
    
    127
    +    4a82531c96a20ab008e7f5a903e85d46a81fd3a3, d5a1b559235a38d527e8e363a325705fa0325602,
    
    128
    +    b7451cb6159a573736cf674e586c75daabd62ae5, 1fed58f610b57c1190862819eba6f7bc5396b08d,
    
    129
    +    7d7ebee6ce113fff252f1b923fbbbad83b1221b8, c3ffdb5a2ed4a5f2488660cfbd310670e43fe803,
    
    130
    +    5065490489ee87d5a898b8dc125e4f38ba295c43, 7e657aa3b4f761f66239c73dbf67fae6a6249f12,
    
    131
    +    0d62a56dc454699790a43a57ffa4258ff909b3f5]
    
    132
    +  linux-4.9.y: [26323fb4d717e11a69484c6df02eeef90dba7ef2, 1f0c936f431d98611fff5ef7082380f087da1578,
    
    133
    +    5ddd318a4715f4806aba256f33db1f0f3ab043db, 11ec2df9c02071a7c0a63a1febb53e76cdee56ac,
    
    134
    +    45a98824bd79b1cf969beadb6288438b66082f17, abcc3e5f0079b850dc4e343f53de1476ac6f5e5c,
    
    135
    +    3adb52ab29760624cd59ea0579317a24c4827e9f, 4d8bd3e2f6b1e45d8e080030f2554476e7c18da7,
    
    136
    +    734e687d1d7bcddf2548eeb5a4935a186f452b69, 44f1eae7fe6597381ce550027fdfa2e578a96ad8,
    
    137
    +    2bb5de42f254bf5addedf17c9c25c68d65639b55, 9eedeb72c4127726b2f3d62b4c7a163f67d721ab,
    
    138
    +    8f96937ee30484aebf687f33e65e8be7ecace13a, 2adc2f74449f7d65ee20675aa2987c3a7446bfab,
    
    139
    +    8b1bacc3218c75707175782ed70c2aa916d366bb, 83d7658362cc65e3d8c71b6002b107dc1f5bc55a,
    
    140
    +    9e37da4c3de1b6cca215a8515491de75360022ba, 87a1fe36250d65e0bffb0199ebd144ea80f87cd7,
    
    141
    +    a590960ae6ea94a8b35b5abd52ba680dba62db66, 276e300447109c92a4f807d4ed7da01c5f590568,
    
    142
    +    34900390e96663cfe5c23e254baaf49664be8836, c1ddd99a029636e234a800f28790a60d6ac0318f,
    
    143
    +    44f1eae7fe6597381ce550027fdfa2e578a96ad8, abf67b1e788194a2d13a8e77f05a44cbf9eae655,
    
    144
    +    b73d68788f79a4906a5ef977fca58297a3d22482, c5aa687060a85d849574ad014639f93b1dc98ea0,
    
    145
    +    09402d83395f6b377841bcf9460aeee37501486d, 06d7342d8498b7426ab50368436417cdf6ed1923,
    
    146
    +    fea3c9a54012227b30e73f5fb3d132c103c7aa84, ec86a1dad0c00757ceb49e86b4c10dd7fbc380cb,
    
    147
    +    98911226d51ea50dd8cb33cfb5a90be39872401b, a1745ad92f50e95b6c2d101cd9b77253969ddccc,
    
    148
    +    d3eba7744075dc55f367364b5ed2055b5e3d5687, 40532f65cccc5056b50cf1ab07a9a41445b24aa8,
    
    149
    +    c26a6bea26b356fb3539cdf5b2e348a5e528aa7b, af57d43c908fe9b06dc555b400eca68562262eca,
    
    150
    +    d8fa9ed041d31cd3a22fcc6498f12a63b70dfbfb, 6c5e49150a51b0210710246b61a972300a274dcd,
    
    151
    +    90ca269463c55e99e3e91c667a821c6303f207ec, 31fd9eda7f69e0be0d0410682fc0d4cd76fe3699,
    
    152
    +    18bc71dff630283333ccea760efb398dbe282a72, 557cbfa2221110761d6c26085c6df43d48425598,
    
    153
    +    46e24dfc2dfe0062a77538698c84f13b24ce9b2c, ff546f9d83d320bc81b72bd2ccd4ebae45d3d714,
    
    154
    +    98911226d51ea50dd8cb33cfb5a90be39872401b, cda6b6074cc6f94ba4cb69a6c8928c1cd19fe291,
    
    155
    +    77b3b3ee238664df176ed44dd4658e578186c6d3, 9eedeb72c4127726b2f3d62b4c7a163f67d721ab,
    
    156
    +    f67e05d1506a24f329589c27952d776f977161b7, cda6b6074cc6f94ba4cb69a6c8928c1cd19fe291,
    
    157
    +    2585e4b41cd690a3d40163b63fc4f7c68b1d8337, 7552556f65af7db6b2bad828beb4c633cb7d8533,
    
    158
    +    6236b782eba37a028972bdfd654773ff2e283a22, 14eb41363919106e50092ed85acb682f30b898bd,
    
    159
    +    961cb14c615d13a823963585dafdc19ee9e9ba85, 34900390e96663cfe5c23e254baaf49664be8836,
    
    160
    +    7013129a4034ea2168a0ccb32d7ddfefe9123333, e5a83419c957edff9290a7e09b951f44af7fa2e2,
    
    161
    +    70f822be66083155a96c157825907dfeffc621cd, 765b60870ae6d2c51ad985b62fcbc60e0c62c824,
    
    162
    +    90ca269463c55e99e3e91c667a821c6303f207ec, 14eb41363919106e50092ed85acb682f30b898bd,
    
    163
    +    6ac85d22332118d2dc449536110a31a5ca3956b0, a27ede1bedcb21b8514f9bd9fcfc37773b816701,
    
    164
    +    e21257ad836df1ae91c37a7c6f99eddf7d97148e, 017219b598b4804ae23eb1447d24da13030c3fb2,
    
    165
    +    a175d5194a8597ae13c0240d560b4f575e406048]
    
    71 166
       mainline: [99c6fa2511d8a683e61468be91b83f85452115fa, 87590ce6e373d1a5401f6539f0c59ef92dd924a9,
    
    72 167
         61dc0f555b5c761cdafb0ba5bd41ecf22d68a4c4, e4d0e84e490790798691aaa0f2e598637f1867ec,
    
    73 168
         39b735332cb8b33a27c28592d969e4016c86c3ea, 258c76059cece01bebae098e81bacb1af2edad17,
    

  • issues/CVE-2017-5753.yml
    ... ... @@ -35,9 +35,49 @@ comments:
    35 35
         Further work went in in 4.16-rc1, 4.15.2 and 4.9.81 and following
    
    36 36
         for mitigations (Mitigation: __user pointer sanitization).
    
    37 37
       Ubuntu-tyhicks: Variant 1, aka "Spectre"
    
    38
    +  bwh: |-
    
    39
    +    linux-4.4.y has most relevant fixes but is missing a backport of
    
    40
    +    304ec1b05031.
    
    38 41
     reporters:
    
    39 42
     - Jann Horn
    
    40 43
     fixed-by:
    
    44
    +  linux-3.16.y: [1b2a12a04fe7233e49dd5601815469bf40fa4749, 56e8e5a33f3e6214685da30b556f93b02f26c82d,
    
    45
    +    15224fb82d3bb0d72bdac57391131e72fade34d3, ae732f0da724f69f81c054c1b2014e2b144f2256,
    
    46
    +    416020e03245a1a60d5de2277149571e8c3d25c4, daa41d548d5b088304957529529307105017f8f2,
    
    47
    +    0510dfd3cc0f01fbea0857736afc2e06c8c59014, 6e8bca7c8e4ed97ce71aa50113ab90525c21fbac,
    
    48
    +    aaafddb9c55db1b3f015062f73bbe2c76c528cc2, c81e7a89b4844ebcc88c81f40e4b2b2516e2793d,
    
    49
    +    8f483696e8edb46461472afa27a764ac6a11929e, 98ce99aa23b43c3dc736cd0354537fca029d69cb,
    
    50
    +    49731da00f0f2160cdcaeaf2daa711f6b7061663, 8c34712ac217fff16d0d225bd48d68af40c33038,
    
    51
    +    3feddbaccb94069b3b7bbeb3476e76e7907f2c9e, c270bd1cc653058717b1234d65f9d262315ea2ed,
    
    52
    +    f5e5a9d5013ba3902045cad1e0809b535fa49ffd, c2453bdbedac62eaf0a94dc007b778e79c6878e7,
    
    53
    +    bac58dda1aef970651788b3eb6fcc67561314a1f, 58bfafe0fd61f23334a00159867661c3e3d35bc9,
    
    54
    +    9ffb15cb898ad23326266aac346ac0c0813362ea]
    
    55
    +  linux-4.14.y: [9298e868dddd820829f814cd25a0f28c92036af7, 5a3e4b399ebc994516f7b6bd8ae0584027e72418,
    
    56
    +    e0d753568c16f123e4805b7136734f3a83403fb6, a5dbaf87684c81693854a87b4a6c46460fc7a731,
    
    57
    +    649c1de819afc90cb6699dc04f5340009dd3783c, 3ea4247ec1b7efc423cf4f75450ebf5cffab9ed8,
    
    58
    +    67c05d9414512e1f9040d29e37e3d5533d8c51dd, b955239cf4ea953eb5fca5409a5524daf20f642a,
    
    59
    +    8459ebcbd6ecbbefd6455315985dc0da1a450b13, e72041f70c3c7d149a8c444262173b7e70e3d4f8,
    
    60
    +    478742cf80b732f6c3227c572184e18b6e8bcb05, 4820d42835b2741fc18b8f6135c90dc1128974bc,
    
    61
    +    437ac7b6868da05620764c143c0e4f7aa91e8fc7, 31c5b332189ec6692ddd92269261db93c835a4d9,
    
    62
    +    2406eb9f4568098f2353f1c9267dbe7e7f4a546b, 5f40de41ccae0c17105d8336e44d704dc5500a50,
    
    63
    +    edaf1538d3a5620862544a20aab14cb601787e1a, 0035134041207f990e0756e2a6f63b7dc3bfe95b,
    
    64
    +    98116c32d3b4b60bc1add46a81ed4f991ef02a7d, c9daf8144642b9daad69ab50e9cba5ecea2c8e25,
    
    65
    +    863b308dbb1945949529a0e523c34636430884a7, 6f6eb84b14aca572ebe50984be94e036075e6e2b,
    
    66
    +    753fc48e595a24eac4d4476a421c36307a7fbcb5, 8b4cdbbb29d4eb34f02d5e1419789b53c3cbb930,
    
    67
    +    bebe3994ddafb0298cc0d3365ca2881a87e3fa39, 2e19277e1df539cf94b435042fbad9bdb7775ab6]
    
    68
    +  linux-4.9.y: [26323fb4d717e11a69484c6df02eeef90dba7ef2, 11ec2df9c02071a7c0a63a1febb53e76cdee56ac,
    
    69
    +    45a98824bd79b1cf969beadb6288438b66082f17, a9bfac14cde2b481eeb0e64fbe15305df66ab32e,
    
    70
    +    abcc3e5f0079b850dc4e343f53de1476ac6f5e5c, 5cb917aa1f1e03df9a4c29b363e3900d73508fa8,
    
    71
    +    820ef2a0e54c4bed27758e393d09157d0d48c94c, 18bc71dff630283333ccea760efb398dbe282a72,
    
    72
    +    d7f8d17406d62f0c8b20a9100d34d0e203557fe1, 899ab2cf91389aa3e27c341a9858dc22985dae2f,
    
    73
    +    579ef9ea20d67a80a0bc5d093259ff6e97087d59, 8c33e2d23a6821cb7d608011c3d2f54accf4212c,
    
    74
    +    1f03d140e2f509ae27f21d229930e707436a07ac, e06d7bfb223e6babd7a7f8586e9c25b87272b841,
    
    75
    +    ae75f83e79e4b2de7981d34ddcceb54178098bea, 065eae4be83d8d2bea325c11610ebaf836e1cebb,
    
    76
    +    398a39311c0b67ff1d886f9861ae5251f8a7cad4, c3193fd49f6f0a9b378379f8fd3a95f01172d477,
    
    77
    +    c26ceec69576cb61157d2487812fb2776e125260, 0781a50a30d37230147954a3dd15bbfcebfc2398,
    
    78
    +    359fde6bd0ec91c284641965e5c5c45a1fab6d51, eb99bd6341cb3039d0b9d2b7f89d5f2ff98e9676,
    
    79
    +    93f3aff1d910c5363a42c2c18dec9939cb0d58c2, 297f8eafece7c4fcabe60b7fc445d497541487e2,
    
    80
    +    244a6d39d68b3729cf63a2d7b137c7e975e83300, 6310a11fce7b9c5c0ac7654f40d6fcc9f48a1240]
    
    41 81
       mainline: [99c6fa2511d8a683e61468be91b83f85452115fa, 87590ce6e373d1a5401f6539f0c59ef92dd924a9,
    
    42 82
         61dc0f555b5c761cdafb0ba5bd41ecf22d68a4c4, b2157399cc9898260d6031c5bfe45fe137c1fbe7,
    
    43 83
         e4d0e84e490790798691aaa0f2e598637f1867ec, be95a845cc4402272994ce290e3ad928aff06cb9,
    

  • issues/CVE-2017-5754.yml
    ... ... @@ -39,11 +39,141 @@ comments:
    39 39
         This flaw only affects Intel processors. AMD reports that their
    
    40 40
          processors are not affected.
    
    41 41
       bwh: |-
    
    42
    -    The list of commits for mainline covers arm64, powerpc, and x86
    
    43
    -    (both 32- and 64-bit).
    
    42
    +    The fixes for mainline cover arm64, powerpc, and x86
    
    43
    +    (both 32- and 64-bit).  For linux-4.4.y, linux-4.9.y and
    
    44
    +    linux-4.14.y, arm64 and x86-32 are NOT fixed and have been
    
    45
    +    ignored.  For linux-3.16.y, powerpc is also NOT fixed and
    
    46
    +    has been ignored.
    
    44 47
     reporters:
    
    45 48
     - Jann Horn
    
    46 49
     fixed-by:
    
    50
    +  linux-3.16.y: [f9a1666f97b32836058839ab03f49daef0528ca0, 7b31cc057cc19f414d20f4c5c0d3b252441b8742,
    
    51
    +    082345aaa10a01ef140240a1d9f864a3cc17436e, a606925a28b389f1c726851fe35f07917ffaeafe,
    
    52
    +    5a322c0ca6ad629240d0a1f19304160ef2d31a91, 4a86410f47b8c6e134fd9eeb8808007fa54de956,
    
    53
    +    58370efdb9e21815ecfadd12f4073a9584a431f2, 379ec248223b343872f71ec502dbdbf05e064818,
    
    54
    +    6a3fe2c11b0c3686ba6cdfc57dcaf4759d6fe595, ef940cac4eb4714f8fa93f8ae857ebe1508df42e,
    
    55
    +    33c7732274af0330804480d9472b26a67047f078, 1f30b9849d6a59834d7f9f11e232e52958a1fbb7,
    
    56
    +    e36d606e53a8d4cac574cbb22b006f9129b88f5f, c8c9f9fe74b2402c24221ebe7a3be3e48d500870,
    
    57
    +    88c38c3fedd878e608e0eb6a90a74d3ee11ae696, 6ea3e97f1db2adeb219fcdc451ab6ec85f6eb0ad,
    
    58
    +    8eb0a71f15bd4e5b798c3fbe2f9932a69318a437, 8c88582f4d3c3052f03e394c3d1b4af6744ed8d8,
    
    59
    +    748165213beda6f96381357327ad461f70c7b881, 63d893d87b8feb2e548fd38e9b2a958b2a030934,
    
    60
    +    76ebcf5a9d44c2f52ce41ae289c6d74c74dd2955, 99216cae9cd0cbd8eb20ee4abc836698a4ef4321,
    
    61
    +    b7d94254937440e0fe2e63b48d8eec91c4c5836a, 56e8e5a33f3e6214685da30b556f93b02f26c82d,
    
    62
    +    15224fb82d3bb0d72bdac57391131e72fade34d3, 84f67d9e273a5512a712a566b6d777a241943838,
    
    63
    +    c3de339f17f9097667dd1ecf908a1014848487bb]
    
    64
    +  linux-4.14.y: [662fd946aa4637a822bff0ec02afd59a8e2c2ba2, c4bc398080d80008e7d4a8cff528b8f3e8d8fb63,
    
    65
    +    7b45ad6e0fd7710cb5a5fb9a6bdd0632f510bf50, beb899c4bcdfb006293a593ffe31c9f13ec7c66b,
    
    66
    +    49c01662d3177e1814ceb52337add473fb4d264b, ee8e8b2df6d3f2a4ce25182d18964f891760ac65,
    
    67
    +    b17459342c55a209014a783d74bff6a0a5374339, 2c8e9099aecec2baaac8d34c7b823493f2d0eeed,
    
    68
    +    88569f5e3a5648331066b49dd6918b8c70067ae7, d8f29ac7363778f38dab7bcb79ca076b8534904c,
    
    69
    +    06f9acfe0abcc9386bbeee8438b87f90ff2e04d1, 032fd2e383cb112789bcbb9a728dd4d96a1c280d,
    
    70
    +    de4c8bbd6e1b631fa5f38e75453e331244ad7028, a0edc4947db9a3cbc6219143ff72e163ad7dbf80,
    
    71
    +    6472c50292d4e4b342f4ea4e3e46e7786ca5c99c, 29606f10f399dd159ab6718d05060294b29a4481,
    
    72
    +    b72e0abe99abaa4e64db83776c11ff6847e829cf, 1765d0a565ee2585cf7b400e81be9a4da96fd7da,
    
    73
    +    acefb4516bcecc7d084205e00fe2de589d8259bc, b6167aeb9faf5966daca3f9f973e1b428a43510c,
    
    74
    +    1b0eddf0a1d1beabc2f3b23bf807758667c30fc7, 3440093266b786d8b8b2506ea788f4462437cd7a,
    
    75
    +    763f7eaf606281ccfaa2f95445219f797697ed70, 752d01704ad18371fa6d15ef16f5dea7972be821,
    
    76
    +    72a2beddcd3240047552de69ce45a28029c7e56c, acfee9b8e27e7b5d69276e8b804fed7ff5071c10,
    
    77
    +    f3d2b767e912b11d146b9c9922bf28efeda0cdc7, a4b07fb4e5a6aef3b87a6540cc04cf972525a723,
    
    78
    +    8a2533407f4d60a43effadf7b62825d213cd678c, b9feab7dcf86df222a405df3e0d95b85741a2d73,
    
    79
    +    ffcb80ad79e8c3d87b43f2c9ee4b9170c7ec12ea, 61fd4049e6760eb8832d4e0bec592d8a810b270f,
    
    80
    +    1bcd98df0f50b28a5fb40eeb2cb7a17a02820232, 9f006b0247234e6448e5fd04b5bcb0c56c968698,
    
    81
    +    35531133abf37ea2f00673a0953e397c286f7c7c, fb9dfabb6e803801b9e88ee6c0d56d3b54531b95,
    
    82
    +    088baf5de12eb7660e20f3f4efc1cf270acff5f4, e08aa2f1988a7d4ded9c9674fe18857ee5c6fc53,
    
    83
    +    d230c1917f57c3beee2e0204a4c8c58999758b95, e0eb34665d2eecddfa7a1810b76fae52313c1286,
    
    84
    +    8b82023b7fc2c3734aae23bc03ed5937e67f7388, c125107490107fc4ce6bad0d9b45fd5e33bfa3f3,
    
    85
    +    7aef823ee7e9a74de0d2665d116bde557aa134ca, 9617ee896217558a2488b6dc71968a4489fb18b6,
    
    86
    +    c796e2324094f098575e47ec6d19f22cc4a4f9b9, 954339c41cceca991c0aec6dd3b7e164c5b9f48b,
    
    87
    +    b63812b81349e5d1a35107e2464547187bc25a61, 36a72ab52c8d969a7a302082f52731c1be0e9ada,
    
    88
    +    c5548af97ae98f9d9e6ae5a9a005e605bd3c06b5, ef4b38472d6b1bf587554dfc7d5ab7abc835c1a5,
    
    89
    +    33d9d7836f0fa02777667d72bc815c12fbe61cac, 3dfd9fd8d897214b1a880c7fd8ed36b88faa1c02,
    
    90
    +    e08acdb9620bcd4c55128cad07e625cd1825e533, b5bef29785ff990a90238d4f59ccbeb656134eeb,
    
    91
    +    082b7521a541a66f1fed68b1f76de6a3b910495e, 3e133155f22d59b0085ef63cbcbcfbd96c4d0b70,
    
    92
    +    57849de13c7da3385611a1b9aca5c6040ef7dfe2, 151d7039757b71ebd9d170af0944562f51149372,
    
    93
    +    211ad3fdf63383772d492add846da4b0b2266531, 7930cb29fb5feb6d18ffc20a83a1d3e5afac7a8a,
    
    94
    +    88dff1ab04d2792492e3f7e166d039f0dc4e1a09, 7adf28df2f0bdeb2141f6e8edc2b746d4a6cc11f,
    
    95
    +    1af9b74bfa59250f69578f6e6424aae7cb46d063, 67f67244f80a37fba03c9e6011853dba94952c7c,
    
    96
    +    b4660939afccbe1d2af5d066d1337f1b29c87ae8, 98f42e3f849412895171d096b901bfa3ff0fe004,
    
    97
    +    83c7e4977221da397ac37119c50a1b21cc6a6677, aea4ead5aba7d0990e007d55b806b1e7859a8bed,
    
    98
    +    58168505a9f13a60b3465fbdd85c70a560640a41, af17c6526b60d52a35033fede9461bd9fbfa5a70,
    
    99
    +    5a3e4b399ebc994516f7b6bd8ae0584027e72418, e0d753568c16f123e4805b7136734f3a83403fb6,
    
    100
    +    968a3bb156424a9e4ea7aa1eb2779b6e86b5a63e, 22e64ef9cdc3eee09e230855e01f1a3826494ce7,
    
    101
    +    026b3f23c970a22165ffdbd47a2a0cdccfd8c009, 6d8b7d3934b2c4f718441784823fbaeaa4c5327d,
    
    102
    +    11caf810bd078e7d09be9f58250818f6595e78de, 627700e4558db4abe37261d80fbf8fbef1ef16cb,
    
    103
    +    bcac5d36538ff417429ed942aa0392a3c50a4783, 9488c6b916535c7df2e99b8e3928faa5ff59b150,
    
    104
    +    b434c155ab4411d732bcafae699bfc35e9847151, 9472d895cdc4a9abfb000bd071b1e036cebe3333,
    
    105
    +    4b5158cefcbd3132c9d382252dab4889c1bc8b56, 5dc597185411ef22cdb9d29563a4f447f9999afd,
    
    106
    +    517bdccc3af650316046801fdcd828d7b6aa42ba, d6eded6c94530cb2f359f1fbffcb5f92ee0fa8b2,
    
    107
    +    b4a9ffad970244d0a349e4e06e5bb332790d7715, 2245d95d9f7a2746af23962e212ea556dc4ea653,
    
    108
    +    dff1a7e6c3ae2b79cdc23503d732a2b8c19a0296, bf434b31bad640ef4ec34e5f92c5dc95b9e4ed44]
    
    109
    +  linux-4.4.y: [8a43ddfb93a0c6ae1a6e1f5c25705ec5d1843c40, 4b35dcb5e048cde1a68603d5ad2d8ccaf3fb1e4e,
    
    110
    +    bed9bb7f3e6d4045013d2bb9e4004896de57f02b, edde73205b3fdde8c8a3adfce78cc6d0de72386b,
    
    111
    +    003e476716906afa135faf605ae0a5c3598c0293, 9b94cf97f42ca30fe9b5010900fa6e1d6855a9f6,
    
    112
    +    d94df20135ccfdfb77b1479c501564e9b4ab5bc9, 487f0b73d82611a2dc48d7d78409e2e9d994006a,
    
    113
    +    20cbe9a3aa2e341824da57ce0ac6d52cbffaa570, 407c3ff6a24c7cb418b77a124d17e282f9622037,
    
    114
    +    5fbd46c4be78174656b52e1b04d3057a5dd7af66, 0c68228f7b39c96cabd89bee3e1d6bd55926df80,
    
    115
    +    c52e55a2a82d3a44189810d35717d81cb4cf61d4, aeda21d77e22fb382c51fd3f6bbb18df69bc032f,
    
    116
    +    b9d2ccc54e17b5aa50dd0c036d3f4fb4e5248d54, 3e3d38fd9832e82a8cb1a5b1154acfa43ac08d15,
    
    117
    +    eb82151d0b1df53d1ad8d060ecd554ca12eb552a, 0731188fc74cc2237975a2b5bedd36e2463ef10b,
    
    118
    +    3b4ce0e1a17228eec71815d7997e49e403ebf2a7, 20268a10ffecd9fcc04880b21fc99a9192394599,
    
    119
    +    fc8334e6b3e5d28afd4eec8a74493933f73b2784, f127705d26b34c053e59b47aef84b3ea564dd743,
    
    120
    +    500943e57db8d3e298e98f595f835c5b613e843b, e345dcc9481543edf4a0a5df4c4c2f9597b0a997,
    
    121
    +    dea9aa9ffae11c91285335cc3215b4f0e48e8139, e405a064bd7d6eca88935342ddb71057a9d6ceab,
    
    122
    +    2dff99eb0335f9e0817410696a180dba25ca7371, 28c6de5441740f868a5b371804a0e8dde03757fb,
    
    123
    +    0651b3ad99dd59269e2ec883338ab8fba617e203, 8eaca4c7d9f167209a9cc568ff028c0a3b0deb2d,
    
    124
    +    3e809caffdd7beeac731feb16788873c3bdb811e, 750fb627d764eb66430c36961b94ab0002694c02,
    
    125
    +    e4ba212ec64109b17fb8653ccfa2ed2c6e3e8217, 7f79599df9c4a36130f7a4f6778b334a97632477,
    
    126
    +    3e1457d6bf26d9ec300781f84cd0057e44deb45d, bfd51a4d715b6ef44bd01b9fbfc13da936f93d76,
    
    127
    +    c18b1bda49334cbef67d5b9fedbbe20e28566088, b33c3c64c4786cd724ccde6fa97c87ada49f6a73,
    
    128
    +    a4c1c75373bf17f185edf3d8b2a64c50c500c785, 6dcf5491e01c3d1135497d0661bb5b35a126b9d8,
    
    129
    +    c18b1bda49334cbef67d5b9fedbbe20e28566088, b33c3c64c4786cd724ccde6fa97c87ada49f6a73,
    
    130
    +    d013f41d0cc509513beb61bea7e5aebfef8521f7, 07c7aa5e7e8ac83768246822b61ebffbdea61ff7,
    
    131
    +    6349cab425ce91ba71676fba5aa6089cae0e6474, 1e8014e74b141979f0cf65bfabe9a077879b11a1,
    
    132
    +    433d7851e5ca9ce7b9a46d95c23f2b6927fd5d2c, 73492b6860129bc3b87b1730486940d0850bfb23,
    
    133
    +    72cf81e43ba4d2c43877ad85afd0417577d610e7, 999d4f1961fa002bda138ddfe9119965421f85da,
    
    134
    +    7ec5d87df34a90758cf2aaf6824bb748454a8f35, 977614061c3db07abd9b3d8c94088fd866b858a8,
    
    135
    +    6b1c99e275c034e4650044a7bb1a0bc274e1eb45, ed73df0b7f23c95b3243a0f4bfc40f962e61d349,
    
    136
    +    5991ee90a270537a8a04751f0097b82274ebc177, 145ebf95fb346528dd276c3e23324609e5f4d3f6,
    
    137
    +    7ca8316cb94f394999f0d512f30984b512f64958, 8dd311f1ec740b05c851d65bab9cfdde26e35a8a,
    
    138
    +    9bfecafe84e628c5dff9cbeaa4b6e73560adb925, 973439da1137a066f6b3f478c930edff1879dee2,
    
    139
    +    920a541397f7b897cb2d0db4be3889df332899f7, c3892946315effa323954134c2f8aeda51e9e68b,
    
    140
    +    11c76e64332f0f6f10ea8c2e2612fd4601a3e0d7, a46ca307a405edda96daf54a5d8baa6778753e82,
    
    141
    +    5c2ea7f7bb2102a6b8caa057af628d1ee7783e24, 95e4f102222aea0c9ff89a5a04c44612d9e400e8,
    
    142
    +    1e8014e74b141979f0cf65bfabe9a077879b11a1, b074e0bd527686da77d4c7efbe77ecc52c470234,
    
    143
    +    5c2ea7f7bb2102a6b8caa057af628d1ee7783e24]
    
    144
    +  linux-4.9.y: [13be4483bb487176c48732b887780630a141ae96, 8f0baadf2bea3861217763734b57e1dd2db703dd,
    
    145
    +    ac2f1018ac210cfedcfab82dbafbda4e2db7ed08, 0994a2cf8fe4e884bad4810681117a7d0096c8e7,
    
    146
    +    7a92e20d157f02d0259e2799dea43c9fa1a4541a, 639c005daeebab077596b034fecd6b8902a88024,
    
    147
    +    19377944317f7d1f706d7da2c7cea5c4bcb7440b, f881e626849c62641a91a13cb5344908c6613d11,
    
    148
    +    f43f386f0bf0380fad5483be3ac678eeee934e95, 67fab0d4acb3556134127ac285b625f715b12ca1,
    
    149
    +    be6bf01f4caa523433030a2267df57d6afefa53d, 604db49610853bffcc65029886688ef151469fa8,
    
    150
    +    61b7a404fa132ee0ffad04b0018b8d01ba5cf026, c27cdea56c546d0a6aa9114d9f5166404f3f14dd,
    
    151
    +    1ce27de4011e57460d454f9bedd301e5b7757e68, 1972bb9d92066fcf7deb0d798e02c88caa45e035,
    
    152
    +    2684b12a169ee244ffc05d34234b0a3dec238c40, 0b5ca9d99599087971a3cd7634a0b61d4e2653e3,
    
    153
    +    6a2b4117614c5d4239d1120b08591b2d296f4f53, d0142ceb7926b81738e1fc122b109f67128d2762,
    
    154
    +    05ddad146d02b2cb05f8c06b2c3b3c365372a66c, 3df146178706bf39cfcb22d7fe1a378af6dc5896,
    
    155
    +    cb7d8d7e6737cad77d5eaba9f9c95f3322706198, 23e09439aa460e4e194c8d2542a16977ee8ed142,
    
    156
    +    50624dd12d6df936f80cb9f02e9a0e40197b5d91, 8018307a45a90ab2eecfd03d48b7efb31707df37,
    
    157
    +    169b369f99affebb24db16f4fed58a2f8ff4060f, 8c2f8a5cc15b90674e0144e453544b7bfb1340df,
    
    158
    +    b72c26e911c566c78743d7973103925007d103c7, fe5cb75fd2dd51746fd391c7f6d18485e6a44f76,
    
    159
    +    1817d2c2fac1b277d97c5a54316e6bfb430d0268, 2c2721754a7f193c98188d07ee335b124ae2df77,
    
    160
    +    402e63de94afdf7cd64e4eb209a8a77310e02d2c, 59094faf3f618b2d2b2a45acb916437d611cede6,
    
    161
    +    e71fac01727a9495f08de9db5259089bee311766, ea6cd39d230f71e27facc0667c1986504e5b0f54,
    
    162
    +    92fd81f772673ee51381337f07b1da94187de542, 47f3cea393ab5188d1a1409259e71099314dc530,
    
    163
    +    beca4e2d994464f5a0f629c1ff91b98398725efa, ec61bafb2abd42a148d41143570732052a577fc0,
    
    164
    +    4e6c2af2ba93ee8709695835920fc57148e4b397, d88f601b9ac9d2b819bb9d947b272d1cf1c36665,
    
    165
    +    43fe95308d276bdfd133f5951cc25565e39982ec, 11ec2df9c02071a7c0a63a1febb53e76cdee56ac,
    
    166
    +    45a98824bd79b1cf969beadb6288438b66082f17, 91b7e5cdc80a3b684154cf0983f22d22ec9b29e5,
    
    167
    +    1b92c48a2eeb8e4c77a27c93052ba95dc6e1cdda, 404ae546c7d1927b877d24bf447a462a5c5a5ad7,
    
    168
    +    0d92cf7f29e6ea8565546c5685b34e633300d8e8, 9a0be5afbfbb1d14efdc98a6615fc52082243bd1,
    
    169
    +    ae1fc8de51b10dba40cbd54959b5ba0a311c0861, 0a61cd6caed72ecac8cbb637f6498e17a33d73b1,
    
    170
    +    efe8bc07c47fff196bbc0822e249a27ae0574d24, 00e40620a51ebee4ea002ec2efcd64f1960cb964,
    
    171
    +    9d914324d966497f4d40cfa9333cbe55150cc09b, 48cc95d4e4d6a1265b7f728182d6dc62de849b05,
    
    172
    +    c3b82ebee6e0d92431c92ee80393c023d550c8a1, 0ef9f8289edf1d335fb2bd3c162521528823b585,
    
    173
    +    7db0fff62f52c3f23c39262b9e037d8b43dfc88d, 6aec12e1869e31839f317c02f81a92c393222f71,
    
    174
    +    1f0c936f431d98611fff5ef7082380f087da1578, 9fed3978c39b27b27eeb676301b7ba960a74170c,
    
    175
    +    ba4f9c192d3b655af9a24e0b8273e58d9ed8aa63, ec0084d082137b73460303b39f4089970a213ad7,
    
    176
    +    51cbb3b34c8972e0096ed8d5cd4abfa586567852, 98df74652bfa95856f3ad8cf7b220b01e4a39aaf]
    
    47 177
       mainline: [7bbcbd3d1cdcbacd0f9f8dc4c98d550972f1ca30, c05344947b37f7cda726e802457370bc6eac4d26,
    
    48 178
         146122e24bdf208015d629babba673e28d090709, 49275fef986abfb8b476e4708aaecc07e7d3e087,
    
    49 179
         4831b779403a836158917d59a7ca880483c67378, c10e83f598d08046dd1ebc8360d4bb12d802d51b,
    
    ... ... @@ -74,7 +204,6 @@ fixed-by:
    74 204
         decab0888e6e14e11d53cefa85f8b3d3b45ce73c, a62d69857aab4caa43049e72fe0ed5c4a60518dd,
    
    75 205
         7f414195b0c3612acd12b4611a5fe75995cf10c7, 87faa0d9b43b4755ff6963a22d1fd1bee1aa3b39,
    
    76 206
         694d99d40972f12e59a3696effee8a376b79d7c8, 52994c256df36fda9a715697431cba9daecb6b11,
    
    77
    -    a9cdbe72c4e8bf3b38781c317a79326e2e1a230d, 3ffdeb1a02be3086f1411a15c5b9c481fa28e21f,
    
    78 207
         d7732ba55c4b6a2da339bb12589c515830cfac2c, 2fd9c41aea47f4ad071accf94b94f94f2c4d31eb,
    
    79 208
         f5a40711fa58f1c109165a4fec6078bf2dfd2bdc, f2078904810373211fb15f91888fba14c01a4acc,
    
    80 209
         1dddd25125112ba49706518ac9077a1026a18f37, 42f3bdc5dd962a5958bc024c1e1444248a6b8b4a,
    

  • issues/CVE-2018-1128.yml
    ... ... @@ -9,6 +9,8 @@ comments:
    9 9
         I don't think this is practical for 3.16 as the protocol change
    
    10 10
         seems to depend on message signatures which were added in 3.19.
    
    11 11
     fixed-by:
    
    12
    -  mainline: [6daca13d2e72bedaaacfc08f873114c9307d5aea]
    
    12
    +  mainline: [262614c4294d33b1f19e0d18c0091d9c329b544a, c0f56b483aa09c99bfe97409a43ad786f33b8a5a,
    
    13
    +    c571fe24d243bfe7017f0e67fe800b3cc2a1d1f7, 149cac4a50b0b4081b38b2f38de6ef71c27eaa85,
    
    14
    +    6daca13d2e72bedaaacfc08f873114c9307d5aea]
    
    13 15
     ignore:
    
    14 16
       linux-3.16.y: Protocol change is too difficult

  • issues/CVE-2018-3620.yml
    ... ... @@ -11,6 +11,22 @@ references:
    11 11
     comments:
    
    12 12
       Debian-carnil: Will be adressed in 4.18.1, 4.17.15, 4.14.63, 4.9.120, and 4.4.148.
    
    13 13
     fixed-by:
    
    14
    +  linux-4.14.y: [aefe1861bc156102ac5d5be18cf781a76537c119, 39991a7aa8d527164a87f90bb18b07b2699ed7d0,
    
    15
    +    83ef7e8c0cb72510588ee8b96f5cf30c1ecd9270, 8c35b2fcbe6a86be93aa7cb9c4842e3c70b77620,
    
    16
    +    aff6fe17f52815e6ebdbf82b69f3edf669808eb6, 3d98de691c013ea4e60360db93b885fe9db15c37,
    
    17
    +    a4116334be3921b0309a9bfa6f808c4663e45f3c, 4bb1a8d8f832084df867351e2b8240e957cac2ec,
    
    18
    +    202f9056085f9380ff82fff5218e343c3f244956, c6374a6259fd10e5fe450bd10cf75a8e04d1b309,
    
    19
    +    b9cdf143eb9c24536750823097635da6bb7e362f, 49221fc7e775656e87978aa56519fab12bb2560b,
    
    20
    +    a20c88c2a346dd90ce244f73647cd6bd8e1cacb3, b37de2cf27a7bc9ad51a72670d902ce71fc9da1e,
    
    21
    +    40b696da70cfcd1d38be557c3bc7d87cfa25dae6, dc6c443e175bebad177c3d81d9c16bf7002cb4ba,
    
    22
    +    a5f284feeb2071f4a381fccf1c8c9b3e05b7a465, d4c1ad0615ff7fd078870791446745442f969798,
    
    23
    +    ce1eed46b7b7b8e2c8dc515dbb07968241a0208e, 06f412c63545b1dec8451f6eda007a2d40c08e58,
    
    24
    +    36f50a5cd27601ae304830f1dec250b4988002ce, 7cefa38bfc5829dfdcc4ebf92f5db9e7e783f97b,
    
    25
    +    202f9056085f9380ff82fff5218e343c3f244956, 7418d70862178363f4ad39ee645e3530c8ff9a8b,
    
    26
    +    59463ec29cacd63844e27fbefd34847fbfead956, 3f2e4f5dd83478b41ee273a500477cbf20266d23,
    
    27
    +    d4c1ad0615ff7fd078870791446745442f969798, ce1eed46b7b7b8e2c8dc515dbb07968241a0208e,
    
    28
    +    06f412c63545b1dec8451f6eda007a2d40c08e58, 310f2a6e3ad39a9349c82d575e92d906fbad37c1,
    
    29
    +    ec4034835eaf9aba4399e3c6770c3e6d6cc09504, d85c2999a7b5e924172f0cc21f5804bbb1f34d69]
    
    14 30
       linux-4.18.y: [1e56c506b35b5d3ac16f58953390b67edd302734, db279f71938540f01cc6dea834ac67a0e7c02e7b,
    
    15 31
         056dc0fa4c114901b036eee50ac209943e0efa7b, 0c5e6259358e9a5eb07b53f9ee21f93ab85fe44f,
    
    16 32
         adb3336455817311300e3414367c6f18eb8a5d95, dcd1b1099b59cef17fdd5f90ee564e7b304619c2,
    
    ... ... @@ -27,6 +43,22 @@ fixed-by:
    27 43
         43b0b90df51125979137b4ca9debb5c479b8e7de, 9fc384dd5354b46ef967f7187764a485935b0dc6,
    
    28 44
         862b9e18a0a33b79635122857ee9c20733542271, 0ea75fa0f6bd8bb79bbccdeb77b313bb9463bde3,
    
    29 45
         2ff13cec042e5793bbcee126729c49d1a4869583, 22b734b0c850139bb0cd31dcaa37cde7f00ccbd6]
    
    46
    +  linux-4.9.y: [bbd07cbb1076de03d896c9c3787081b1080e8c99, 2c9b57e4474d93222bcb6e7f901fd1e71ded699c,
    
    47
    +    60712274887fcd4ad5eb8e01796022b6b202143c, 33182fe97add6e83c195e9d0f7297a6499563b52,
    
    48
    +    5b2ec92f70f6d4084d23bf42391fd27fa03e8c4c, 432e99b34066099db62f87b2704654b1b23fd6be,
    
    49
    +    7c5b42f82c13365b8284b5945f5ffa9f88380dd7, e3923475ebb1b503668dfdb3ba90e2ebd46931e6,
    
    50
    +    1ac1dc14671f531134f29755f98386f8e168b810, c4b998c88f86971400b556520ba55c8ca96fd8dc,
    
    51
    +    53527af79dc940a225efa266f6320ae9e8dae5e3, 3f0eb66f652ceb5985b9b619e33fc61519121045,
    
    52
    +    93aed2469df1fdef8ed97d6cbb6dd042181fe46e, b4f17de89e7aaecfc67a173ca8607899ee8707c3,
    
    53
    +    03b3614d4d6febe96117b9e5edc4941a8265e844, d9f378f64c0ae3d76c1828742557c6c0ccc9e977,
    
    54
    +    4656dfb6b5ddb2c7e6120b8a8d0b144445bf5914, 5ebf3f8d5b56412973ca3f2363dae52f795c6700,
    
    55
    +    7e464373357dd6ff33a1a7373d5e596ed1dbb219, e79d049743f1466084df5708cd0e052b0d586548,
    
    56
    +    d21c27185b6f2c32d4b029d1b5c0661702099baf, 16848eb10e9e0989e5898dec204f0967c483f044,
    
    57
    +    1ac1dc14671f531134f29755f98386f8e168b810, fe0f40491bba65d904edd0147184bd9882cb7b7f,
    
    58
    +    f8d42d5c02084c936f0a7830e011b4395f30f06e, 7e5cac813b40cfd2ec77f7653287b388e3e59291,
    
    59
    +    5ebf3f8d5b56412973ca3f2363dae52f795c6700, 7e464373357dd6ff33a1a7373d5e596ed1dbb219,
    
    60
    +    e79d049743f1466084df5708cd0e052b0d586548, 2421738c164f79868d7bbe13a38129e7a3ffb6f3,
    
    61
    +    ef3d45c9576415e657da3eca10216df1bb8d7ffa, f3913ee267da0722c3731997545a6c4747323779]
    
    30 62
       mainline: [50896e180c6aa3a9c61a26ced99e15d602666a4c, bcd11afa7adad8d720e7ba5ef58bdcd9775cf45f,
    
    31 63
         2f22b4cd45b67b3496f4aa4c7180a1271c6452f6, 6b28baca9b1f0d4a42b865da7a05b1c81424bd5c,
    
    32 64
         10a70416e1f067f6c4efda6ffd8ea96002ac4223, 17dbca119312b4e8173d4e25ff64262119fcef38,
    

  • issues/CVE-2018-3639.yml
    ... ... @@ -33,36 +33,62 @@ comments:
    33 33
         (and respective stable releases).
    
    34 34
         Basically: 3b78ce4a34b761c7fe13520de822984019ff1a8f^2 ^1aa7a5735a41418d8e01fa7c9565eb2657e2ea3f~1
    
    35 35
       Ubuntu-tyhicks: '"Variant 4"'
    
    36
    +  bwh: |-
    
    37
    +    linux-4.4.y, linux-4.9.y, linux-4.14.y are missing a backport of commit
    
    38
    +    af86ca4e3088.  linux-4.4.y is also missing KVM support for SSBD.
    
    36 39
     reporters:
    
    37 40
     - Jann Horn
    
    38 41
     - Ken Johnson
    
    39 42
     fixed-by:
    
    40
    -  linux-4.9.y: [741c026d1a0c594f7ad509f44488ef29582fed74, 88659d5fd9bea7f6afb227c6d404de750b368b45,
    
    41
    -    3effee64a9993dc5587fb39f0da4455769e53d26, 0f5dd651397b264903e8becc511af6cf384c273e,
    
    42
    -    cf21f58ae6f264e0a10d9736be97342627cf9837, 24e4dd97af40afa4d45e85a32d9c2cc81425a62e,
    
    43
    -    a80714172abca6413d2d6505be64723ae73a903b, 6f70a553666dd8c4fa370eaaa41380eec593229c,
    
    44
    -    19e3a2bec95e966921689ae39117f9dbbaffd99b, 99b13116965f16b2e608e7796cd59198eee5bf06,
    
    45
    -    f854434b37bbf8953900226acd6139081f60d3da, 99318eca2c7ab3250b9614043b9ac6077ff2cb46,
    
    46
    -    7a2d2358ba9b6de29be0a98c8290479df32604b6, 4812ffbbfcac35270b82292e84e8e7187088c8b8,
    
    47
    -    fd01e82efa269b7e295533ec7b2d93aa8adf670a, 439f2ef884306976f22b42f709c1ccdf04278987,
    
    48
    -    5ed7788df973455378e987fe221bef0661fbe03a, 89c6e9b599c573802de1b2fff6a9ccd99c3c4e57,
    
    49
    -    a078e3e81964c31079627dd32c3ea714d5b1531e, 4272f528da381673a8e7845c93daa88b8aa4f4e9,
    
    50
    -    51ef9af2a35bbc21334c801fd15cbfe01210760f, 0a112f104548667f5618477ff0f2a54ee626addd,
    
    51
    -    ea055f7d43fb3a9d56e80d0116104555d6dde3f7, 036608d62a838aeb63cae0adaf8ac773cb53148c,
    
    52
    -    c71def81cd07e1bd74da468ae6abe1ce62e3157b, ab677c2addbb128f334c4906f27a0285a67d2180,
    
    53
    -    094c2767c4f02c36eabc27309d78b04f4a216e88, 05a85a396f3989e9ac953785d9dccfc7cd0110f2,
    
    54
    -    bf3da841edae882de545d2d19b1fae205cab8d98, f8cd89f5e05d49422315e60ec2db9fcb66d25aca,
    
    55
    -    f79f0efe8e1816063f83926c946026d83b9b287f, eb7b5624be3e6249a880310be486245db15a5f5c,
    
    56
    -    dbb264a253c8b07259d55fb3373b783fcb641b04, 6fdd277a9326c5ef3fe94999c9c319ad64333fdd,
    
    57
    -    3a684641619ff0e06b8d4cb8c2ffbef304c9bdb1, 69e9b0b1e04001a743927489bb8b9a10344810d8,
    
    58
    -    4a58908fa1476c600548f82effc75bcfa890454a, a7c343228e5c32802431e6cc5b855ae61eb4db72,
    
    59
    -    f69e91f2c4ce59deb66bd30150e5153c08873ae9, 5a63725cd18fcee2af6ec46ccb856b64ad3077b4,
    
    60
    -    53c434e735fffbf8715a1778ce44387131e0b080, d0cb78f5e4214db86b12a9448d8ccaa005f43cb9,
    
    61
    -    1189cbf52ad35cfd04a715016200ea81dd4c708f, 7c0b2dc44956533c5aac95f07575feef7b63344c,
    
    62
    -    b7b84401576d3858e9573d69d8287e182444f8e9, ea99935b633bd4766a679e51b173197c750fb00b,
    
    63
    -    599288ec9e20d9772e6e8a27aeae021f018c7336, ec90464d96c50f90bfe1bde6dea748a6c962313c,
    
    64
    -    0ec827f974e198c609c2f258a5a1f11f9af48bb2, b0ef8c72b3d70505ba7fd72af6b1e3fc9b3ae9bc,
    
    65
    -    b965592a07a248ef254d9d421bd34a6b548db21f, 3394ef1a7efc08e3c185ac2446f06284847ccb37]
    
    43
    +  linux-3.16.y: [4172af7e06994104deeb53e344f53cf4173ce144, cacee1eef8ec25cdf5d4f44827b3badfb6818bef,
    
    44
    +    b72dd55897316db40e0bc2aaa3ac8493ea4ae751, 2ba071eb39d6691d6d29eec434448766dcdc2f5d,
    
    45
    +    df53e5d9c5c7debdfb99e84caa3903dfc47cbd4e, 65d362d590594c95c2f33ba96b314dba6d1b97ab,
    
    46
    +    45f1e691477f26a60dc1a0d3661d58b99848dfdb, 1cd7b5bcb30c69d05964cbf20d7410e82083b95b,
    
    47
    +    0e21a7d7e2a39539fb2771099ce5faa408805f03, 4d9f99b5b77826d916216f40304c497c7057eb42,
    
    48
    +    29f1c2ac73cd880aee2578fbfedf7f4179ca172f, 2218ec3989560033dfda6026f8de6f1efaac0438,
    
    49
    +    601100765f6ac070a677669da1d9d96bbe3ec9dd, 883b3421d7b9c027a34888e690d6aadba1943aac,
    
    50
    +    acdf4971010ee1f01b7e8986a9ef11b8c88b85c8, 4781d92a0499db5f1840bf1570960e68c4872c3d,
    
    51
    +    6b065a1d23b27cc826b1f86b01c800d9a86efb71, c0f77718114bfdc56711dbaa411825839b7a190e,
    
    52
    +    284aa1550489336c3e5fd7b7ea3269b6ad96fe01, 0b51874e298c685fd20d68f075c70b63b54633f2,
    
    53
    +    9e48fb3d80a91074ba3f7e0219edde53ec03ef92, 92856049f6e54b124805b3335c84c79937934655,
    
    54
    +    34be01c449e2f06bf019979efde3bbf9c5b45c82, f8983158cf25740f5fed217344c446928b521f06,
    
    55
    +    9ba2801ac0e44bbe21a5aba4a2e599f9a0792e9a, 6be901da18db5d686b293a16688adb8eecdc7fc3,
    
    56
    +    704a0bcfa8751fa8d3381a2c375a941a3643ca6f, eca4fd360aeea799e1f65a58e97f4f9ce89df4fe,
    
    57
    +    02a92f36ec3af60e14ce516028b5ff82ca472a40, 3b5fdffe9114e3c0cc07e5d8e6d6f89bb0d07847,
    
    58
    +    67d57c4c51a8e9849cdb79ec795b499b760efc83, 39efb5c8a13f65a2a14a97c0b9f43f65d3e7633c,
    
    59
    +    f93d91a5b5345998092d9db00c8be9683207cbea, afd515a46ecc30dd613d70657ddcaf16939ad2d7,
    
    60
    +    8a12c48125b5752e5f5a2aa55cd218d455a119c2, 340cfe03f30081d124632fe7408065b1bb54adeb,
    
    61
    +    af108cc9145299e70235a574e65b5b34ed13ef9c, 70d5392690143d20185c144003e4acdb92203eac,
    
    62
    +    9ed451be3e8c5f0e23537925d00483d08f2f3ca1, dbfa4250cef087f7b7809f5031301d1e78135145,
    
    63
    +    f486422f0959ab05b8e4f694e8f31b590e7554ad, 9433d17d1407cb6b858a7f3d9bd5b21e5e69d5da,
    
    64
    +    4e99bb051d3e60dbb323c5562375c96f56d56ec4, fbb7b98887d4fe5e556b2146857b9c43b6c469f3,
    
    65
    +    8963b10319ec195059f8a65c049303f84cb02d38, dde241727d8213c0f29102642a6be2629df4c596,
    
    66
    +    5a9cbccff42fdecd30daaf8e88d4779cce055ac7]
    
    67
    +  linux-4.16.y: [2cd883a4cc87871db17dbc52398a58321af209b1, d1ee580200e9937cc4e3f0ff1d45c3cfb2532f9e,
    
    68
    +    0e303bbda22ac4a655f0a2bfdd51cda209562ddb, 4fa760f200941e88187c0241ce5df72e8ec9cd97,
    
    69
    +    2460962b14b78b47ebfeb744bd9e09d813c8236d, 569e3b16770b6d3c8ea08bb41678473f786868a3,
    
    70
    +    64656a6bb5a0203c7dbd5ca49788d1177d385c2f, f3e6aff543a560ac8b9373cd50a8427443ab181f,
    
    71
    +    67fc823943c0ecc1f7aba293ef264c42413a7082, 88e65eda8b0db4245a6ee8eea873a307824f057c,
    
    72
    +    57c8073bcd42ac63751c6150a32cec9621e32f61, efa66ff263de7f5bb2655240c3a95d5a802e8289,
    
    73
    +    2cd9a9a41a70ce5bdad4b82850cf3cbbedd8f484, a06b21c754e819fa7cff7665ce9dba68dc874d2a,
    
    74
    +    556f9159f47d0bec7e10a16c39af2e471d64d1db, 54d97c1d92a10428f4fbe1b39d9cc668b7bc505a,
    
    75
    +    280ea3678f2465851c4f71c248fad54f9f2ca711, 7074687d3a6539d5204c1c8310e98d1714094b2f,
    
    76
    +    62fffc7129840290e191569d02e406d356037804, 6672d85a43c4aab30840a3654abec7aead1150cd,
    
    77
    +    080b78edb23cadf8125118ea9be4390a737b1aea, 04832dda9484916a728d2524cef5088b3d567626,
    
    78
    +    2f9083d1c00e05c1ae128d7b1b683067ea07d0b7, a92b6ffb737fe3214251d3827bddefc012ead5a6,
    
    79
    +    9378c64a76a07988b933383d947f919fc8a1d4ac, 96867367cf81cc2cc5f8ed5d43102665be563f77,
    
    80
    +    feb2788b090bac2201af4517b7c341cb3f6bd53a, b5e5979dba3936bce29bb5e733c5bfeddd5d2c88,
    
    81
    +    bb82d388b5e860aed39d6bd4202ed3befe1a58d0, 08140850070bd14cf4fc3fc3f3c60eb55f6b9a3c,
    
    82
    +    c3a8aab35b7f162aeecfe4d2de0bc24a692c3b24, 6384a9130622ac42ccde466e499c5bfbe3e38f89,
    
    83
    +    7eed4a87774784b39613d67a3be356421b834a61, df35c3e66e6da210fed4a011722644cf1de590dd,
    
    84
    +    44e405201570aed0cdc3f1eeb018fa21d72d69a5, 0f106929848115b57fc2029b036499313df1491e,
    
    85
    +    6e03d4bed37848762a34f14ca7059435addbd42c, 2658f4c3abe23fbb3a6cfafcfe0139f5b0f16f3c,
    
    86
    +    8bddd4295a6c0f5ad2955f96026e6d74e1a8d0d9, 10e436d078ada2ed9f429035d35e70a03b2d9891,
    
    87
    +    6a4872a0cb222aa6e246aac5fe8a9ba397fde560, aaf6e76e6a30481458ce7d87ec6d35b39903fed6,
    
    88
    +    6f350863c98e0f95634178ea81bc8ff08db14cab, dde9807143e7580c3832858f62001742011da264,
    
    89
    +    bd4b410bc5ea560107126a3df18e9233baaec9f3, 95271aeb93d4681c65e2f94969b23ef6070367a6,
    
    90
    +    7445962ff2d652bb957722ca1a08a92d09f3e5d7, 677af592349708498671b0d9290912acb2f203e4,
    
    91
    +    75e3417f898fe1d2451e7ceffe93db5c66772b0a]
    
    66 92
       mainline: [1aa7a5735a41418d8e01fa7c9565eb2657e2ea3f, 4a28bfe3267b68e22c663ac26185aa16c9b879ef,
    
    67 93
         d1059518b4789cabe34bb4b714d07e6089c82ca1, 1b86883ccb8d5d9506529d42dbe1a5257cb30b18,
    
    68 94
         5cf687548705412da47c9cec342fd952d71ed3d5, c456442cd3a59eeb1d60293c26cbe2ff2c4e42cf,
    

  • issues/CVE-2018-3646.yml
    ... ... @@ -11,6 +11,64 @@ references:
    11 11
     comments:
    
    12 12
       Debian-carnil: Will be adressed in 4.18.1, 4.17.15, 4.14.63, 4.9.120, and 4.4.148.
    
    13 13
     fixed-by:
    
    14
    +  linux-4.14.y: [fc890e9b571fb273e714bae5de682226eaed9cb2, b84b9184651dd2a003459293ec7caa58e5423562,
    
    15
    +    8eb2860590ba188c8d9fbd5497ac4bfd9848201b, 26a6dcc7134b7f45e0058cd735148afd2715f67a,
    
    16
    +    6beba29c66bcab61457173c7c36638fa3f5824b5, c5ac43ee8c77b1a38d5223bb8a688b2116f1f958,
    
    17
    +    728ac48249f620182eb7ad065a0d7064b6f17e2b, 33c8be23981353f141937b37e0659eb5c1857c02,
    
    18
    +    bfa4f8aeb0f38c68b3060b9c27ee533c89404ad1, 9552b7df0eb1a8846890c05d375fb3b89f9c2fe6,
    
    19
    +    d20d8f7f6a92ce1211b27af925bdd6e2beebfab8, 35c67d5baad3e2ab745393cbfeb6c6cc9ac6a334,
    
    20
    +    63f2c9b0d42f7afcdd698025885dd48bc73a8a5b, f02f2ad9e711881bcb62f0fc64084c32af3600e4,
    
    21
    +    62f43866636d08efca34b87cd2bf8b0f49edb27c, 2a82e5e51fc0153024c52d64ae00dcf006311c80,
    
    22
    +    f3e68ab4e778e575ab9fba10894387d177af510a, 7f2229c92b9ea4d4b1b50671b9fe5afadbf0b4f4,
    
    23
    +    c2fdbbb47ca834b9b19fbbf0a9b740146a508b84, 77c8220e0d01d8c1c85343fa9472fd957c4878a0,
    
    24
    +    a662a3d89f1618a33540ab345945bbcd812f9057, e993d9c0376a143f0407ec025c44569cb0a6032c,
    
    25
    +    84f5b2512f6f6902e732adb84e9646a4ee18c51c, 10309cbf1e3802cec871cf940b8693ae8421f46e,
    
    26
    +    916f4623d213b9801ade314b1bf678a113d67af3, 0299ca42458cbdee213c47c1c2ebad4432fbb358,
    
    27
    +    7b0cdac526410afd2b5c3e0069366799087db790, 1c67bf4ca05328323bac6cfb79c91c69228c2090,
    
    28
    +    ac10995a749844c1e98c2a5ba650eddf26d0eba6, e7a979648a66fcd8968848069c0b48219af156b4,
    
    29
    +    de6749ddf3db5b9da14721973390159addc0ec1c, de88416d6141b745c4e22e1a9345d142642e036d,
    
    30
    +    d0e1ca1045849f6aa71491b7ca9566cbdd94a32c, 8e523a1da19e9cfcb4e801bcba2fd1e2d6f5aace,
    
    31
    +    15e55ee33d89b9cf1745daf18260ee351058571c, e25726b1d30247589f36101c7e1e0a9b378fe407,
    
    32
    +    8e41ddda308f9ac29fb9dd85d6e6bde7d3a29910, 476d29ab70e710b7610148f9c38896bb004f08c2,
    
    33
    +    fc083988b6aa43fe3210792011647c1c1124ab5e, a20c88c2a346dd90ce244f73647cd6bd8e1cacb3,
    
    34
    +    ae217320c17df01283add6f8a549c3fc70580423, 40b696da70cfcd1d38be557c3bc7d87cfa25dae6,
    
    35
    +    c6613521abbc2685ef334af32e455589d14f1d8d, c6a43c04233bdf63104b3c7ef6984cdaa3aa9ecd,
    
    36
    +    9baeea57aff241b5b454db99373479dae157a30f, 0d6b3085975fafd909d26d37310c641f8e5e1be9,
    
    37
    +    88f8090b9cbec23fac99eb4d7b4ea785c3beac51, 06fd9ef44f7c642710dbe482d342c22ee2e1cd13,
    
    38
    +    18f891ef7a631cac76e25d09a37f582690d852dd, aef13e1e96b7449f8346392ad1e38db86e6e75a2,
    
    39
    +    f9625775c30945439e412413de813404046e6f97, dc6c443e175bebad177c3d81d9c16bf7002cb4ba,
    
    40
    +    6a0bea042dcacc087587e6b44fb3e74ce0c26e5c, c15396d3f74f6cd7c084bdcc1004714a40cb268a,
    
    41
    +    1110cb2a343f506287d46e0c614512afaa7c7906, 9eb0a3cce0089d93ad031c85ce6f2aee09fd4015,
    
    42
    +    e456004eb77734e274e520c83ad9be76736e622c]
    
    43
    +  linux-4.17.y: [f3839aa4a2b9b04b5b4144412e436d6811972d2b, babba06adfa67263406ded5a3bafefb5037660e9,
    
    44
    +    aef565d8587c335aef7fc9ba500ebcef531f6d39, 165ae0b7dacbd442b7b20bd32588f28e58acc884,
    
    45
    +    77db3823f0a5b6a9e3addb2e796dd9f08c14b02d, 73650e0724c0ccd0f85e215d0c8866853391718d,
    
    46
    +    186aeab679e342e7223d8ff5f39027695168110f, 9087f7047f6e6d25ada0cb6643ec27aba810d77b,
    
    47
    +    06ebc9fd87005eb56c08aea3f2844aca5fc37c78, 2910ebe9281197ab65c953543bb3db6f69d043f8,
    
    48
    +    8346482d765318a50a01942bc23b4959656d15a9, 096700fb08dc07989030f30a01b1b7c70e445d4b,
    
    49
    +    3708ec490bf9dc8243571c0daaf4503590e6caee, 0daddfa173ab932070494f3c3b530b0ce6fd2db9,
    
    50
    +    e486e3cbe16d76ef1aa6fde8a5f9c6d723c26009, f85769f1400f9ac8ea9b1ef1ab0fd94f63fb9033,
    
    51
    +    50eb78a07451ee490d3bed0a1ab2065a3364d0fb, edaa3d5446cbd847f299dc12e66b2020d273091c,
    
    52
    +    8efd53e73ae385947d22c6d0c1fc6dc718048a63, 9431927cfe0353f8263f230fe8bc30d4a84a6aef,
    
    53
    +    1db21b84cb84bffb9fb67650366d32b555920326, 348a22db760a954b7de6d77645dfe231dd172340,
    
    54
    +    aab5ed8057b4ae701f32814a86d3d9a01b828942, 813e6ede42f26c74d936c8413db52d4243b2aac1,
    
    55
    +    f38baa5bc13b62c8beeaa44ee495060f45e68f90, 7bbd5a4751ac4b96ca7982de15ba4daab76a0cd7,
    
    56
    +    0a06117dd3ee22d731560c9c27a18012f2454bde, 0689d66648a5c48b04afec54125ab5812eea2ec0,
    
    57
    +    49fc27f3c0f3135f1f9f9623f9962fff97de95ef, fc7107040fa1d4b9d1c9f1b8da53af0579748e62,
    
    58
    +    5a591c95e2a285dd1f3a24e2dbc1d62f43ad0057, fe7463bbef767b3d91e9113c69fea975a035388d,
    
    59
    +    f22496974121fe4f1530350c9a53631e3f02f878, 6da20c6faec12bd0303b19d65beda0e0cfd70a3d,
    
    60
    +    3983c579df7826b4b49fd984b3ba3dca94cbe1f4, e86575c798b0826a44877ab839a3aa0381b677b1,
    
    61
    +    6c57ce2dd9fc11d93ad025e1910a8a0726bdb4c9, 7fc6f0e2f7cb515ec42e12c632de8c36d756f4db,
    
    62
    +    912d10ace8248917bb691dbae20ad1df3916d50f, f4e44a41979effe99d054d5c24c9058826fc805f,
    
    63
    +    48f9b6554c21c137556d8a1a70c94b575ce3d334, 0cd091501932ad434023bc21495714fee1e1b9d3,
    
    64
    +    63a759508f3ec9af3b5014c371651db91a505f8b, afb059e688f22d860575cddea281534504397756,
    
    65
    +    569f08c9b0d0e5761e9a542e8da0fa0d2ca9d25d, f5129286ade4ef85ad8ad26a4a43ba54136f3755,
    
    66
    +    6896e226e6d732576e27d463c42f3139f847f3d6, 2566de674202af2205a927b5ad1d704ce4145627,
    
    67
    +    7654bab9d7d0aac9a9b7903483afcb1b180140b0, de446dc3cf1ba99a0a7f1fe3286cc1b5d4579807,
    
    68
    +    a09777bcd347a2c9ee701b054c10eca3171baa43, 1273eb5fca6ae07004ecb1ebac27f2bdc367afe1,
    
    69
    +    ea6c7c5dab4517bf21579363d66c48c991cc9027, daceaeec3e486247f455fe524055bdca26ca791a,
    
    70
    +    4fef280872237c114d732db2f0460b00747ac895, 6dcc5103dd5b1d63c1e7c3a1df5aa221a8eb92e7,
    
    71
    +    f6b2c7253830473fedb8b5680894660e78e03aea]
    
    14 72
       linux-4.18.y: [71ef4580dc21eebd43a8b22a372fce2e28235728, aa5de56185a07b1d32f90e1d23a6d4b56fb04a24,
    
    15 73
         2883a1f89b50caa8dc1a6cc73d35c8b4642eae20, 6249d3232f222d454a4da3e6ac7efd01137f8400,
    
    16 74
         74f1c7a26b6064f278a9f2ae0c30d4c23955e835, 24d9fd272ec02eea118bf8cc36a0276087e4a23c,
    

  • issues/CVE-2018-5391.yml
    ... ... @@ -47,4 +47,6 @@ fixed-by:
    47 47
         4077ddb2cb48ca4592d738ea37cd58c5d41754bd, 85e59af99a7f7c9bcd089f2404b405df7ee665ba,
    
    48 48
         5a0f340f5ad6a6cc6518f212802f95b669e8fe27]
    
    49 49
       mainline: [7969e5c40dfd04799d4341f1b7cd266b6e47f227, 385114dec8a49b5e5945e77ba7de6356106713f4,
    
    50
    -    fa0f527358bd900ef92f925878ed6bfbd51305cc]
    50
    +    fa0f527358bd900ef92f925878ed6bfbd51305cc, 0ed4229b08c13c84a3c301a08defdc9e7f4467e6,
    
    51
    +    70837ffe3085c9a91488b52ca13ac84424da1042, 353c9cb360874e737fb000545f783df756c06f9a,
    
    52
    +    a4fd284a1f8fd4b6c59aa59db2185b1e17c5c11c, 5d407b071dc369c26a38398326ee2be53651cfe4]

  • scripts/import_stable.py
    1 1
     #!/usr/bin/python3
    
    2 2
     
    
    3
    -# Copyright 2017 Codethink Ltd.
    
    3
    +# Copyright 2017-2018 Codethink Ltd.
    
    4 4
     #
    
    5 5
     # This script is distributed under the terms and conditions of the GNU General
    
    6 6
     # Public License, Version 3 or later. See http://www.gnu.org/copyleft/gpl.html
    
    ... ... @@ -18,12 +18,16 @@ import kernel_sec.branch
    18 18
     import kernel_sec.issue
    
    19 19
     
    
    20 20
     
    
    21
    -BACKPORT_COMMIT_RE = re.compile(
    
    22
    -    r'^(?:' r'commit (%s) upstream\.'
    
    23
    -    r'|'    r'\[ Upstream commit (%s) \]'
    
    24
    -    r'|'    r'\(cherry-picked from commit (%s)\)'
    
    21
    +COMMIT_HASH_RE = r'[0-9a-f]{40}'
    
    22
    +BACKPORT_COMMIT_TOP_RE = re.compile(
    
    23
    +    r'^(?:' r'commit (%s)(?: upstream\.?)?'
    
    24
    +    r'|'    r'\[ [Uu]pstream commit (%s) \]'
    
    25
    +    r'|'    r'\(cherry[- ]picked from commit (%s)\)'
    
    25 26
         r')$'
    
    26
    -    % ((r'[0-9a-f]{40}',) * 3))
    
    27
    +    % (COMMIT_HASH_RE, COMMIT_HASH_RE, COMMIT_HASH_RE))
    
    28
    +BACKPORT_COMMIT_BOTTOM_RE = re.compile(
    
    29
    +    r'^\(cherry[- ]picked from commit (%s)\)$'
    
    30
    +    % COMMIT_HASH_RE)
    
    27 31
     
    
    28 32
     
    
    29 33
     def update(git_repo, remote_name):
    
    ... ... @@ -31,8 +35,7 @@ def update(git_repo, remote_name):
    31 35
                               cwd=git_repo)
    
    32 36
     
    
    33 37
     
    
    34
    -def get_backports(git_repo, remote_name):
    
    35
    -    branches = kernel_sec.branch.get_stable_branches(git_repo, remote_name)
    
    38
    +def get_backports(git_repo, remote_name, branches):
    
    36 39
         backports = {}
    
    37 40
     
    
    38 41
         for branch_name in branches:
    
    ... ... @@ -48,51 +51,85 @@ def get_backports(git_repo, remote_name):
    48 51
                                          errors='ignore'):
    
    49 52
                 if line[0] != ' ':
    
    50 53
                     stable_commit = line.rstrip('\n')
    
    54
    +                commit_re = BACKPORT_COMMIT_TOP_RE  # next line is top of body
    
    51 55
                 else:
    
    52
    -                match = BACKPORT_COMMIT_RE.match(line[1:])
    
    56
    +                match = commit_re.match(line[1:])
    
    53 57
                     if match:
    
    54 58
                         mainline_commit = match.group(1) or match.group(2) \
    
    55 59
                                           or match.group(3)
    
    56 60
                         backports.setdefault(mainline_commit, {})[branch_name] \
    
    57 61
                             = stable_commit
    
    62
    +                if line.strip() != '':
    
    63
    +                    commit_re = BACKPORT_COMMIT_BOTTOM_RE  # next line is not top
    
    58 64
     
    
    59 65
         return backports
    
    60 66
     
    
    61 67
     
    
    62
    -def add_backports(issue_commits, all_backports):
    
    68
    +def add_backports(branches, c_b_map, issue_commits, all_backports,
    
    69
    +                  debug_context=None):
    
    63 70
         try:
    
    64 71
             mainline_commits = issue_commits['mainline']
    
    65 72
         except KeyError:
    
    66 73
             return False
    
    74
    +    if mainline_commits == 'never':
    
    75
    +        return False
    
    67 76
     
    
    68 77
         changed = False
    
    69 78
     
    
    70
    -    # Find backports of each commit to each stable branch
    
    71
    -    branch_commits = {}
    
    72
    -    for commit in mainline_commits:
    
    73
    -        try:
    
    74
    -            commit_backports = all_backports[commit]
    
    75
    -        except KeyError:
    
    79
    +    for branch_name in branches:
    
    80
    +        # Don't replace a non-empty field
    
    81
    +        if issue_commits.get(branch_name):
    
    82
    +            if debug_context:
    
    83
    +                print('%s/%s: already set' % (debug_context, branch_name))
    
    76 84
                 continue
    
    77
    -        for branch_name in commit_backports:
    
    78
    -            branch_commits.setdefault(branch_name, []).append(
    
    79
    -                commit_backports[branch_name])
    
    80
    -
    
    81
    -    # Only record if all commits have been backported and nothing recorded
    
    82
    -    # for this branch yet
    
    83
    -    for branch_name in branch_commits:
    
    84
    -        if len(branch_commits[branch_name]) == len(mainline_commits):
    
    85
    -            issue_branch_commits = issue_commits.setdefault(branch_name, [])
    
    86
    -            if not issue_branch_commits:
    
    87
    -                issue_branch_commits.extend(branch_commits[branch_name])
    
    85
    +
    
    86
    +        branch_commits = []
    
    87
    +        for commit in mainline_commits:
    
    88
    +            # Was this commit included before the branch point?
    
    89
    +            if c_b_map.is_commit_in_branch(commit, branch_name):
    
    90
    +                if debug_context:
    
    91
    +                    print('%s/%s: includes %s' %
    
    92
    +                          (debug_context, branch_name, commit))
    
    93
    +                branch_commits.append(commit)
    
    94
    +            else:
    
    95
    +                # Has it been backported?
    
    96
    +                try:
    
    97
    +                    backport_commit = all_backports[commit][branch_name]
    
    98
    +                except KeyError:
    
    99
    +                    if debug_context:
    
    100
    +                        print('%s/%s: missing %s' %
    
    101
    +                              (debug_context, branch_name, commit))
    
    102
    +                    continue
    
    103
    +                if debug_context:
    
    104
    +                    print('%s/%s: includes backport of %s' %
    
    105
    +                          (debug_context, branch_name, commit))
    
    106
    +                branch_commits.append(backport_commit)
    
    107
    +
    
    108
    +        if len(branch_commits) == len(mainline_commits):
    
    109
    +            # All required commits were found.  If some or all of them are
    
    110
    +            # backports then record them.
    
    111
    +            if branch_commits != mainline_commits:
    
    112
    +                if debug_context:
    
    113
    +                    print('%s/%s: recording commits' %
    
    114
    +                          (debug_context, branch_name))
    
    115
    +                issue_commits.setdefault(branch_name, []).extend(branch_commits)
    
    88 116
                     changed = True
    
    117
    +            else:
    
    118
    +                if debug_context:
    
    119
    +                    print('%s/%s: not recording commits - same as mainline' %
    
    120
    +                          (debug_context, branch_name))
    
    89 121
     
    
    90 122
         return changed
    
    91 123
     
    
    92 124
     
    
    93
    -def main(git_repo, remote_name):
    
    94
    -    update(git_repo, remote_name)
    
    95
    -    backports = get_backports(git_repo, remote_name)
    
    125
    +def main(git_repo, mainline_remote_name, stable_remote_name, debug=False):
    
    126
    +    stable_branches = kernel_sec.branch.get_live_stable_branches()
    
    127
    +    branches = stable_branches + ['mainline']
    
    128
    +
    
    129
    +    update(git_repo, stable_remote_name)
    
    130
    +    backports = get_backports(git_repo, stable_remote_name, stable_branches)
    
    131
    +    c_b_map = kernel_sec.branch.CommitBranchMap(git_repo, mainline_remote_name,
    
    132
    +                                                branches)
    
    96 133
     
    
    97 134
         issues = set(kernel_sec.issue.get_list())
    
    98 135
         for cve_id in issues:
    
    ... ... @@ -104,7 +141,10 @@ def main(git_repo, remote_name):
    104 141
                 except KeyError:
    
    105 142
                     continue
    
    106 143
                 else:
    
    107
    -                changed |= add_backports(commits, backports)
    
    144
    +                debug_context = '%s/%s' % (cve_id, name) if debug else None
    
    145
    +                changed |= add_backports(stable_branches, c_b_map,
    
    146
    +                                         commits, backports,
    
    147
    +                                         debug_context=debug_context)
    
    108 148
             if changed:
    
    109 149
                 kernel_sec.issue.save(cve_id, issue)
    
    110 150
     
    
    ... ... @@ -118,10 +158,18 @@ if __name__ == '__main__':
    118 158
                             help=('git repository from which to read commit logs '
    
    119 159
                                   '(default: ../kernel)'),
    
    120 160
                             metavar='DIRECTORY')
    
    161
    +    parser.add_argument('--mainline-remote',
    
    162
    +                        dest='mainline_remote_name', default='torvalds',
    
    163
    +                        help='git remote for mainline (default: torvalds)',
    
    164
    +                        metavar='NAME')
    
    121 165
         parser.add_argument('--stable-remote',
    
    122 166
                             dest='stable_remote_name', default='stable',
    
    123 167
                             help=('git remote for stable branches '
    
    124 168
                                   '(default: stable)'),
    
    125 169
                             metavar='NAME')
    
    170
    +    parser.add_argument('--debug',
    
    171
    +                        dest='debug', action='store_true',
    
    172
    +                        help='enable debugging output')
    
    126 173
         args = parser.parse_args()
    
    127
    -    main(args.git_repo, args.stable_remote_name)
    174
    +    main(args.git_repo, args.mainline_remote_name, args.stable_remote_name,
    
    175
    +         args.debug)

  • scripts/kernel_sec/branch.py
    1
    -# Copyright 2017 Codethink Ltd.
    
    1
    +# Copyright 2017-2018 Codethink Ltd.
    
    2 2
     #
    
    3 3
     # This script is distributed under the terms and conditions of the GNU General
    
    4 4
     # Public License, Version 3 or later. See http://www.gnu.org/copyleft/gpl.html
    
    5 5
     # for details.
    
    6 6
     
    
    7 7
     import io
    
    8
    +import os
    
    8 9
     import re
    
    9 10
     import subprocess
    
    11
    +import time
    
    12
    +import urllib.error
    
    13
    +import urllib.request
    
    14
    +import warnings
    
    15
    +
    
    16
    +import html5lib
    
    17
    +import yaml
    
    10 18
     
    
    11 19
     from . import version
    
    12 20
     
    
    ... ... @@ -23,52 +31,83 @@ def get_stable_branch_base_ver(branch_name):
    23 31
         return match and match.group(1)
    
    24 32
     
    
    25 33
     
    
    26
    -def get_stable_branches(git_repo, remote_name='stable'):
    
    27
    -    branches = []
    
    34
    +def _extract_live_stable_branches(doc):
    
    35
    +    xhtml_ns = 'http://www.w3.org/1999/xhtml'
    
    36
    +    ns = {'html': xhtml_ns}
    
    37
    +    cell_tags = ['{%s}td' % xhtml_ns, '{%s}th' % xhtml_ns]
    
    28 38
     
    
    29
    -    branch_text = str(
    
    30
    -        subprocess.check_output(
    
    31
    -            ['git', 'branch', '--list', '-r', '--no-color', '--column=never',
    
    32
    -             remote_name + '/*'],
    
    33
    -            cwd=git_repo),
    
    34
    -        encoding='utf-8', errors='strict')
    
    35
    -    branch_prefix = remote_name + '/'
    
    39
    +    tables = doc.findall(".//html:table[@id='releases']", ns)
    
    40
    +    if len(tables) == 0:
    
    41
    +        raise ValueError('no releases table found')
    
    42
    +    if len(tables) > 1:
    
    43
    +        raise ValueError('multiple releases tables found')
    
    36 44
     
    
    37
    -    for branch_name in branch_text.strip().split():
    
    38
    -        assert branch_name.startswith(branch_prefix)
    
    39
    -        branch_name = branch_name[len(branch_prefix):]
    
    45
    +    branches = []
    
    40 46
     
    
    41
    -        if get_stable_branch_base_ver(branch_name):
    
    42
    -            branches.append(branch_name)
    
    47
    +    for row in tables[0].findall(".//html:tr", ns):
    
    48
    +        row_text = []
    
    49
    +
    
    50
    +        # Get text of each cell in the row
    
    51
    +        for cell in row:
    
    52
    +            if cell.tag not in cell_tags:
    
    53
    +                raise ValueError('unexpected element %s found in releases' %
    
    54
    +                                 cell.tag)
    
    55
    +            row_text.append("".join(cell.itertext()))
    
    56
    +
    
    57
    +        # Extract branch type, current version, EOL flag
    
    58
    +        branch_type, version, eol = None, None, None
    
    59
    +        if len(row_text) >= 2:
    
    60
    +            branch_type = row_text[0].rstrip(':')
    
    61
    +            match = re.match(r'([^ ]+)( \[EOL\])?$', row_text[1])
    
    62
    +            if match:
    
    63
    +                version = match.group(1)
    
    64
    +                eol = match.group(2) is not None
    
    65
    +        if branch_type not in ['mainline', 'stable', 'longterm', 'linux-next'] \
    
    66
    +           or version is None:
    
    67
    +            raise ValueError('failed to parse releases row text %r' % row_text)
    
    68
    +
    
    69
    +        # Filter out irrelevant branches
    
    70
    +        if branch_type not in ['stable', 'longterm'] or eol:
    
    71
    +            continue
    
    72
    +
    
    73
    +        # Convert current version to branch name
    
    74
    +        match = re.match(r'(\d+\.\d+)\.\d+$', version)
    
    75
    +        if not match:
    
    76
    +            raise ValueError('failed to parse stable version %r' % version)
    
    77
    +
    
    78
    +        branches.append('linux-%s.y' % match.group(1))
    
    43 79
     
    
    44 80
         return branches
    
    45 81
     
    
    46 82
     
    
    47
    -def get_live_stable_branches(*args, **kwargs):
    
    48
    -    # TODO: Pull list of longterm branches from
    
    49
    -    # https://www.kernel.org/category/releases.html ?
    
    50
    -    # For now, err on the side of inclusion and only exclude known dead
    
    51
    -    # branches.
    
    52
    -    dead_branches = set((
    
    53
    -        'linux-2.6.11.y', 'linux-2.6.12.y', 'linux-2.6.13.y', 'linux-2.6.14.y',
    
    54
    -        'linux-2.6.15.y', 'linux-2.6.16.y', 'linux-2.6.17.y', 'linux-2.6.18.y',
    
    55
    -        'linux-2.6.19.y', 'linux-2.6.20.y', 'linux-2.6.21.y', 'linux-2.6.22.y',
    
    56
    -        'linux-2.6.23.y', 'linux-2.6.24.y', 'linux-2.6.25.y', 'linux-2.6.26.y',
    
    57
    -        'linux-2.6.27.y', 'linux-2.6.28.y', 'linux-2.6.29.y', 'linux-2.6.30.y',
    
    58
    -        'linux-2.6.31.y', 'linux-2.6.32.y', 'linux-2.6.33.y', 'linux-2.6.34.y',
    
    59
    -        'linux-2.6.35.y', 'linux-2.6.36.y', 'linux-2.6.37.y', 'linux-2.6.38.y',
    
    60
    -        'linux-2.6.39.y', 'linux-3.0.y', 'linux-3.1.y', 'linux-3.2.y',
    
    61
    -        'linux-3.3.y', 'linux-3.4.y', 'linux-3.5.y', 'linux-3.6.y',
    
    62
    -        'linux-3.7.y', 'linux-3.8.y', 'linux-3.9.y', 'linux-3.10.y',
    
    63
    -        'linux-3.11.y', 'linux-3.12.y', 'linux-3.13.y', 'linux-3.14.y',
    
    64
    -        'linux-3.15.y', 'linux-3.17.y', 'linux-3.19.y', 'linux-4.0.y',
    
    65
    -        'linux-4.1.y', 'linux-4.2.y', 'linux-4.3.y', 'linux-4.5.y',
    
    66
    -        'linux-4.6.y', 'linux-4.7.y', 'linux-4.8.y', 'linux-4.10.y',
    
    67
    -        'linux-4.11.y', 'linux-4.12.y', 'linux-4.13.y', 'linux-4.15.y',
    
    68
    -        'linux-4.16.y', 'linux-4.17.y'))
    
    69
    -
    
    70
    -    return [branch_name for branch_name in get_stable_branches(*args, **kwargs)
    
    71
    -            if branch_name not in dead_branches]
    
    83
    +def get_live_stable_branches():
    
    84
    +    try:
    
    85
    +        with open('import/branches.yml') as f:
    
    86
    +            branches = yaml.safe_load(f)
    
    87
    +            cache_time = os.stat(f.fileno()).st_mtime
    
    88
    +    except IOError:
    
    89
    +        branches = None
    
    90
    +        cache_time = None
    
    91
    +
    
    92
    +    # Use the cache if it's less than a day old
    
    93
    +    if cache_time and time.time() - cache_time < 86400:
    
    94
    +        return branches
    
    95
    +
    
    96
    +    # Try to fetch and parse releases table
    
    97
    +    try:
    
    98
    +        with urllib.request.urlopen('https://www.kernel.org') as resp:
    
    99
    +            doc = html5lib.parse(resp.read())
    
    100
    +        branches = _extract_live_stable_branches(doc)
    
    101
    +    except (urllib.error.URLError, ValueError) as e:
    
    102
    +        # If we have a cached version, use it but warn
    
    103
    +        if branches:
    
    104
    +            warnings.warn(str(e), RuntimeWarning)
    
    105
    +            return branches
    
    106
    +        raise
    
    107
    +
    
    108
    +    with open('import/branches.yml', 'w') as f:
    
    109
    +        yaml.safe_dump(branches, f)
    
    110
    +    return branches
    
    72 111
     
    
    73 112
     
    
    74 113
     def get_sort_key(branch):
    

  • scripts/kernel_sec/issue.py
    1 1
     # Copyright 2006 Kirill Simonov <xi@...>
    
    2
    -# Copyright 2017 Codethink Ltd.
    
    2
    +# Copyright 2017-2018 Codethink Ltd.
    
    3 3
     #
    
    4 4
     # This script is distributed under the terms and conditions of the GNU General
    
    5 5
     # Public License, Version 3 or later. See http://www.gnu.org/copyleft/gpl.html
    

  • scripts/report_affected.py
    1 1
     #!/usr/bin/python3
    
    2 2
     
    
    3
    -# Copyright 2017 Codethink Ltd.
    
    3
    +# Copyright 2017-2018 Codethink Ltd.
    
    4 4
     #
    
    5 5
     # This script is distributed under the terms and conditions of the GNU General
    
    6 6
     # Public License, Version 3 or later. See http://www.gnu.org/copyleft/gpl.html
    
    ... ... @@ -24,8 +24,7 @@ def main(git_repo, mainline_remote_name, stable_remote_name,
    24 24
                             if name[0].isdigit() else name
    
    25 25
                             for name in branch_names]
    
    26 26
         else:
    
    27
    -        branch_names = kernel_sec.branch.get_live_stable_branches(
    
    28
    -                           git_repo, stable_remote_name)
    
    27
    +        branch_names = kernel_sec.branch.get_live_stable_branches()
    
    29 28
             if not only_fixed_upstream:
    
    30 29
                 branch_names.append('mainline')
    
    31 30
     
    

  • scripts/webview.py
    ... ... @@ -140,8 +140,7 @@ class Root:
    140 140
         _template = _template_env.get_template('root.html')
    
    141 141
     
    
    142 142
         def __init__(self, git_repo, mainline_remote_name, stable_remote_name):
    
    143
    -        self.branch_names = kernel_sec.branch.get_live_stable_branches(
    
    144
    -            git_repo, stable_remote_name)
    
    143
    +        self.branch_names = kernel_sec.branch.get_live_stable_branches()
    
    145 144
             self.branch_names.append('mainline')
    
    146 145
             self.branch_names.sort(key=kernel_sec.branch.get_sort_key)
    
    147 146
     
    


  • Re: [Safety-linux-formation] [C-safe-secure-studygroup] [SystemSafety] Critical systems Linux

    Nicholas Mc Guire <der.herr@...>
     

    On Thu, Nov 22, 2018 at 01:19:44PM +0000, Paul Sherwood wrote:
    Hi Clive,
    this is very helpful, thank you. I'm going to re-add the other lists, for
    the same reason as before, and hope you're ok with that. Please see my
    comments inline below...

    On 2018-11-22 10:26, Clive Pygott wrote:
    I'll have a go at your question - FYI my background is system safety
    management (as in 61508 & DO178) and coding standards (MISRA & JSF++)

    You are right that ultimately system safety is a _system _property.
    You cannot talk about software doing harm without knowing what its
    controlling and how it fits into its physical environment.
    Understood, and I'd be surprised if anyone would challenge this reasoning.

    However, a standard like 61508 takes a layered approach to safety.
    I'm not sure I understand "layered approach", since I've heard it mentioned
    in multiple situations outside safety (security for one, and general
    architecture/abstraction for another).

    Are you saying that the aim is redundant/overlapping safety methods, to
    avoid single-point-of-failure, or something else?
    61508 starts out with the top layer wich is actually technology
    agnostic - simply put if we do not understand the system then it
    can´t be adequately safe - so part 1 does not talk about HW/SW at all
    but about context/scope/hazard-analysis/mitigation-allocation...
    independent of technological issues. Part 2 then looks at the
    technical system (and not just HW) with respect to systematic and
    random deviations from specifications as derived by applying part 1
    part 3 then looks at the specifics of software. So the layering
    of 61508 is a very abstract process layering to ensure that the
    poetntial high-level faults - non-understanding expressed in requirements
    and design faults - we do not kill that many people wiht dereferenced
    NULL pointers - atleast not repetedly if the high-level processes work
    are addressed at all levels. see e.g. HSE HSG238

    In addition there may be technical "layering" as in layers of protection
    and architectural measures - but thats already at the implementation
    level.


    The topmost
    levels are system specific: how could the system behave (intentionally
    or under fault conditions) to cause harm? and what features of the
    architecture (including software requirements) mitigate these risks?
    This establishes traceability from software requirements to safety.
    OK, understood. In previous discussions I've been attempting to understand
    whether there's any fundamental reasons that such requirements would need to
    exist before the software, or whether they could be originated for a
    specific system, and then considered/applied to pre-existing code. Is there
    a hard and fast argument one way or the other?
    The simplest argument is that the goal of any safety process is that the
    safety functional requirements are implemented in the software elements - the
    outlined process (route 1_S) is one way seen suitable to achieve the objectives
    of the safety standards (61508 and derivatives - DO 178 is a bit different
    because the context of ARP 4751A is well defined - so they can put very specific
    needs into DO 178/254 while 61508 is a generic standard and can´t do that.

    Essentially the goal of achieving the objectives is not dependent on the
    process by which the implementation is achieved - verification of the
    achieving of the objectives *may* though depend on the means by which
    the imlementation wsa achieved (but then again is quite independent of
    the question of "intent for use in safety related systems" or not).


    From the software perspective, under this is the requirement to show
    that those software requirements related to safety have been
    implemented correctly, and as usual this has two components:

    * showing that the code implements the requirements (verification -
    we've built the right thing)
    OK, makes sense.

    * showing the code is well behaved under all circumstances
    (validation - we've built the thing right)
    DO 178B (respectively DO 248) - but that misses the essential point of

    * showing that the assurance data (often process data) on which we
    based any such claim is adequate

    and this is the thing that is changing because the two highlevel requirements
    you give are fully adequate for deterministic and relatively simple
    system (type-A systems in 61508-2 Ed 2 7.4.4.1.2) but not for type B
    system because we generally can´t demonstrate correctness nor compleness
    in any meaningful sense - with other words we increasingly simply do not
    know what the "right thing" is and as soon as non-determinism comes
    into play the "built the thing right" becomes a probability as well and
    needs to be assessed as such (e.g. a pLRUt cache replacement in many
    current CPU does not allow to claim that it is built right other than
    probabilistically).


    Here I fall off the horse. I don't believe we can be 100% certain about "all
    circumstances", except for small/constrained/simple systems. So I distrust
    claims of certainty about the behaviour of modern COTS multicore
    microprocessors, for example.
    ..we fell off that horse about 20 years ago but many did not notice ;)

    The point is to accept what has been stated many time alreday that
    safety is not a 100% property anyway - as long as system were simple
    we could entertain the illusion of completeness of testing (an absurd
    assertion since the mid 1990s for many systems) and we have not yet
    fully developed the necessary understanding and tools to actually
    handle complex systems. Also note that this idea of correctness is
    bound to strongly to technical realisation which puts the focus on
    mitigation of faults rather than the elimination of faults at the
    requirements and design level - and that is really why we are so lost
    with current safety standards when it comes to complex systems because
    we emediately jump to mitigation rather than harvesting the potential
    for elimination first - with other words the problem is systems engineering
    not software engineering.


    If you are doing full formal semantic verification, the second step is
    unnecessary, as the semantic proof will consider all possible
    combinations of input and state.
    ...and who ever had a fault free initial specification to start
    with for her formal specificaiton that then was shown to be implemented ?

    the idea that "everything in the system matches the requirments" and
    "every requirement is built into the system" - kind of the corrolary to
    your two components above - does not address the key issue in fucntional
    safety and that is that our reqiurements are wrong because we do not
    fully understand the system and its environment (except for the most trivial
    of systems).


    It's not fair to single out any individual project/system/community, but as
    an example [1] SEL4's formal proof of correctness proved to be insufficient
    in the context of spectre/meltdown. I'd be (pleasantly) surprised if any
    semantic proof can withstand misbehaviour of the
    hardware/firmware/OS/tooling underneath it.
    ...and the misunderstanding of the systems intent by those writing
    the formal specification that then is proven - it is interesting to note
    that 61508 Ed 2 (Table A.1) ranks formal requiremets specification
    lower than semi-formal requirements specification and in Table C.1 it
    is clarified why - reduced understandability !


    However, in practice formal proof is
    so onerous that its almost never done. This means that verification is
    based on testing, which no matter how thorough, is still based on
    sampling. There is an implied belief that the digital system will
    behave continuously, even though its known that this isn't true (a
    good few years ago an early home computer had an implementation of
    BASIC that had an integer ABS functions that worked perfectly except
    for ABS(-32768) which gave -32768 and it wasn't because it was
    limited to 16-bits, ABS(-32769) gave 32769 etc).
    it is not based on testing - no sane safety standard would suggest to
    achieve verification by testing - it is always analysis and testing
    and if it is reduced to testing only then it will for sure produce a
    warm cosy fealing after execution of 100k test-csae... which covered
    10E-20% of the systems state-space.

    The problem of testing is that in the heads of many we sitll have the
    idea that an aggregation of highly-reliable components forms a highly
    reliable system - which is wrong in it self but becomes a real hazard
    as soon as the ability to inspec comonents is so much easier that we
    focus on components because we can believe that we understand then
    in isolation and then simply drop the main cause which is interaction
    (which is in genreal not covered by testing - not even integratoin
    testing - maybe to a limited level by field trials)



    Understood, and agreed.

    The validation part aims to improve the (albeit flawed) belief in
    contiguous behaviour by:

    * checking that any constraints imposed by the language are respected
    * any deviations from arithmetic logic are identified (i.e. flagging
    where underflow, overflow, truncation, wraparound or loss of precision
    may occur)

    This is the domain of MISRA and JSF++ checking that the code will
    behave sensibly, without knowledge of what it should be doing.
    Does anyone have hard evidence that shows that there is *any*
    significant correlation between MISRA C coding rules and bug rates ?
    This is one of the cases where we focus on formality because we can
    even though we have little (or no) evidence that these rules or metrics
    have any effect (aside from them being used in a way that they
    were never intended for anyway) ?

    as a corrolary think about your personal driving experience - how many#
    situations were you in where you got out by violating a rule ?
    the assumption that following context agnostic rules leads to
    safety properties of system is truely absurd.


    OK, IIUC this is mainly

    - 'coding standards lead to tests we can run'. And once we are into tests,
    we have to consider applicability, correctness and completeness of the
    tests, in addition to the "flawed belief in contiguous behaviour".

    - and possibly some untestable guidance/principles which may or may not be
    relevant/correct
    If you have no specific context how can you assert more than correctness against
    context free reqiuremnts which them selve have no assurance of correctness or
    comleteness in the context of any specific system - focussing on what we can
    because we know that we can´t handle the level that actually is
    relevant is a form of deliberate ignorance.

    Coding standards (and this is the intent of the Linux kernel coding standard)
    lead to *readability* which is the maybe only relevant defence
    against correct implementation of the wrong function (or as you
    state above not "building the right system"). That is the expressed
    intent of the Linux kernel coding standard and readability respectively
    understandability of code (and fault behavior) is the key to actually
    being able to detect when the correctly implemented code is the wrong
    solution for a particular context - the requirements don´t do as they are
    an abstraction and as such they focus on the intended behavior not on the
    side effects or unintended interactions - thus matching only requirements
    of perceived generic elements will necessarily lead to missing the specific
    intent for any system in the systems specific corner cases.


    To get back to the original discussion, it is staggeringly naive to
    claim that 'I have a safe system, because I've used a certified OS
    kernel'. I'm sure you weren't suggesting that, but I have seen
    companies try it.
    I've also seen that (in part that's why I'm here) but I certainly wouldn't
    dream of suggesting it.

    What the certified kernel (or any other
    architectural component) buys you is that someone has done the
    verification and validation activities on that component, so you can
    be reasonably confident that that component will behave as advertised
    No - thats precisely what only is true for very simple components - but
    never holds for complex components and any OS is a type-B system

    a) the failure mode of at least one constituent component is not well defined; or
    b) the behaviour of the element under fault conditions cannot be completely determined; or
    c) there is insufficient dependable failure data to support claims for rates of failure for
    detected and undetected dangerous failures (see 7.4.9.3 to 7.4.9.5).
    [IEC 61508-2 Ed 2 7.4.4.1.3]

    Pre-certified OS (or complex libraries) buy you the illusion that you
    took care of safety by giving someone else enough money - thats it.


    - its a level of detail your project doesn't have to look into (though
    you may want to audit the quality of the certification evidence).
    OK in principle. However from some of the discussion, which I won't rehash
    here it seemed to me that some of the safety folks were expressly not
    confident in some of the certified/advertised/claimed behaviours.
    good to hear that - they should not be - because it depends entirely on the
    specific context - the higher the complexity of a system the more we depend
    on looking at the right corners of the system to undrestand
    where they can go wrong - focussing on generic properties (unspecific behaviors
    and their correctness asserted against a more or less random model) gives
    you very little. The higher the complexity of a system the more the abiltiy
    to analyze the systems specific behavior in context of env/Use-case will determine
    the systems safety properties. Even *if* testing could achieve the
    initial goal of correctness the inability to analyze the system would
    impair any effort to understand and thus learn from incidences.


    As I read your original message you are asking 'why can't a wide user
    base be accepted as evidence of correctness?'
    If that's the question I seemed to be asking I apologise; certainly I
    wouldn't count a wide user base as evidence of correctness. It's evidence of
    something, though, and that evidence may be part of what could be assessed
    when considering the usefulness of software.
    prior usage may well be one building block in a chain of assessment
    of a pre-existing element but I would claim primarily in the sense
    of selecting the lowest risk elements - it will not save you any effort in
    assessing the objectives of functional safety - but careful selectoin
    based on prior usage will increas the likelyhood that the assessment
    will actually conclude positively. To the specifics of 61508 Ed 2
    route 3_S (assessment of non-compliant development) the relevance of
    a large user base is also the ability to actually harvest process level
    data that can allow to assess the effectiveness of different measures
    e.g. it is trivial to state that a pre-existing element wsa reviewed but
    without any data on finding, peoples competency, level of deviations later
    found during operations, etc. we can not actually use "review was done"
    as an argument in the assessment of a non-compliant development - and in
    this sense user base is as you say "evidence of something" the trick
    is to find sound procedures how to extract the relevant information in that
    something so as to be able to make a statement on the process that created
    the element. So as soon as you shift the focus from the implementation
    details to the process that created these implementation details
    then the user base becomes the key "data set" that allows to actually build
    an argument - at least that is the assumption behind the SIL2LinuxMP project.


    The short answer is, do
    you have any evidence of what features of the component the users are
    using and in what combination?
    I totally agree - which brings us back to the need for required/architected
    behaviours/properties.
    with an important change - the use of pre-existing elements always
    implies that you are building functionality into the system that
    does NOT match you needs exactly and the mitigation again only
    lies in the ability to analyze the system to the point where the system can
    ither be adjusted to the specifics of the element (by updating requirements
    and design) or by handling the discrepency at runtime (e.g. wrappers)
    in a complex system it is highly unlikely that the requirements anyone put
    on a complex element like an OS is in exact alignment with any particular
    system - not even POSIX 1003.13 PSE 51 matchies any real system 100%.

    Is my project about to use some
    combination of features in an inventive manner that no-one has
    previously tried, so the wide user base provides no evidence that it
    will work (again a good few years ago, colleagues of mine were
    writing a compiler for a VAX and traced a bug to a particular
    instruction in the VAX instruction set that had an error in its
    implementation. No DEC product or other customer had ever used this
    instruction. BTW, DEC's solution was to remove it from the
    instruction set)
    Makes sense. Thanks again Clive!
    Thats the prime felacy I see in the whole pre-existing SW discussion
    that the focus on fuctionality - the argument for using the common
    setup is that the process initially was generating this common
    setup and the measures and techniques to achieve the specfied
    behavior where IN CONTEXT of the common use-case no mater if explicidly
    stated or implied - diverting from the common use-case potentially
    invalidates the results of these measures and techniques. So the
    requirement to be allowed to draw on any process level claims of the
    pre-existing element is to operate it in as close a context to the
    original intent as possible - using common configurations is one
    aprt of this.

    thx!
    hofrat


    Re: [C-safe-secure-studygroup] [SystemSafety] Critical systems Linux

    Paul Sherwood
     

    Hi Clive,
    this is very helpful, thank you. I'm going to re-add the other lists, for the same reason as before, and hope you're ok with that. Please see my comments inline below...

    On 2018-11-22 10:26, Clive Pygott wrote:
    I'll have a go at your question - FYI my background is system safety
    management (as in 61508 & DO178) and coding standards (MISRA & JSF++)
    You are right that ultimately system safety is a _system _property.
    You cannot talk about software doing harm without knowing what its
    controlling and how it fits into its physical environment.
    Understood, and I'd be surprised if anyone would challenge this reasoning.

    However, a standard like 61508 takes a layered approach to safety.
    I'm not sure I understand "layered approach", since I've heard it mentioned in multiple situations outside safety (security for one, and general architecture/abstraction for another).

    Are you saying that the aim is redundant/overlapping safety methods, to avoid single-point-of-failure, or something else?

    The topmost
    levels are system specific: how could the system behave (intentionally
    or under fault conditions) to cause harm? and what features of the
    architecture (including software requirements) mitigate these risks?
    This establishes traceability from software requirements to safety.
    OK, understood. In previous discussions I've been attempting to understand whether there's any fundamental reasons that such requirements would need to exist before the software, or whether they could be originated for a specific system, and then considered/applied to pre-existing code. Is there a hard and fast argument one way or the other?

    From the software perspective, under this is the requirement to show
    that those software requirements related to safety have been
    implemented correctly, and as usual this has two components:
    * showing that the code implements the requirements (verification -
    we've built the right thing)
    OK, makes sense.

    * showing the code is well behaved under all circumstances
    (validation - we've built the thing right)
    Here I fall off the horse. I don't believe we can be 100% certain about "all circumstances", except for small/constrained/simple systems. So I distrust claims of certainty about the behaviour of modern COTS multicore microprocessors, for example.

    If you are doing full formal semantic verification, the second step is
    unnecessary, as the semantic proof will consider all possible
    combinations of input and state.
    It's not fair to single out any individual project/system/community, but as an example [1] SEL4's formal proof of correctness proved to be insufficient in the context of spectre/meltdown. I'd be (pleasantly) surprised if any semantic proof can withstand misbehaviour of the hardware/firmware/OS/tooling underneath it.

    However, in practice formal proof is
    so onerous that its almost never done. This means that verification is
    based on testing, which no matter how thorough, is still based on
    sampling. There is an implied belief that the digital system will
    behave continuously, even though its known that this isn't true (a
    good few years ago an early home computer had an implementation of
    BASIC that had an integer ABS functions that worked perfectly except
    for ABS(-32768) which gave -32768 and it wasn't because it was
    limited to 16-bits, ABS(-32769) gave 32769 etc).
    Understood, and agreed.

    The validation part aims to improve the (albeit flawed) belief in
    contiguous behaviour by:
    * checking that any constraints imposed by the language are respected
    * any deviations from arithmetic logic are identified (i.e. flagging
    where underflow, overflow, truncation, wraparound or loss of precision
    may occur)
    This is the domain of MISRA and JSF++ checking that the code will
    behave sensibly, without knowledge of what it should be doing.
    OK, IIUC this is mainly

    - 'coding standards lead to tests we can run'. And once we are into tests, we have to consider applicability, correctness and completeness of the tests, in addition to the "flawed belief in contiguous behaviour".

    - and possibly some untestable guidance/principles which may or may not be relevant/correct

    To get back to the original discussion, it is staggeringly naive to
    claim that 'I have a safe system, because I've used a certified OS
    kernel'. I'm sure you weren't suggesting that, but I have seen
    companies try it.
    I've also seen that (in part that's why I'm here) but I certainly wouldn't dream of suggesting it.

    What the certified kernel (or any other
    architectural component) buys you is that someone has done the
    verification and validation activities on that component, so you can
    be reasonably confident that that component will behave as advertised
    - its a level of detail your project doesn't have to look into (though
    you may want to audit the quality of the certification evidence).
    OK in principle. However from some of the discussion, which I won't rehash here it seemed to me that some of the safety folks were expressly not confident in some of the certified/advertised/claimed behaviours.

    As I read your original message you are asking 'why can't a wide user
    base be accepted as evidence of correctness?'
    If that's the question I seemed to be asking I apologise; certainly I wouldn't count a wide user base as evidence of correctness. It's evidence of something, though, and that evidence may be part of what could be assessed when considering the usefulness of software.

    The short answer is, do
    you have any evidence of what features of the component the users are
    using and in what combination?
    I totally agree - which brings us back to the need for required/architected behaviours/properties.

    Is my project about to use some
    combination of features in an inventive manner that no-one has
    previously tried, so the wide user base provides no evidence that it
    will work (again a good few years ago, colleagues of mine were
    writing a compiler for a VAX and traced a bug to a particular
    instruction in the VAX instruction set that had an error in its
    implementation. No DEC product or other customer had ever used this
    instruction. BTW, DEC's solution was to remove it from the
    instruction set)
    Makes sense. Thanks again Clive!

    br
    Paul

    [1] https://research.csiro.au/tsblog/crisis-security-vs-performance/


    Re: [C-safe-secure-studygroup] [SystemSafety] Critical systems Linux

    Clive Pygott <clivepygott@...>
     

    Hi Paul

    I'll have a go at your question - FYI my background is system safety management (as in 61508 & DO178) and coding standards (MISRA & JSF++)

    You are right that ultimately system safety is a system property. You cannot talk about software doing harm without knowing what its controlling and how it fits into its physical environment. However, a standard like 61508 takes a layered approach to safety. The topmost levels are system specific: how could the system behave (intentionally or under fault conditions) to cause harm? and what features of the architecture (including software requirements) mitigate these risks? This establishes traceability from software requirements to safety.

    From the software perspective, under this is the requirement to show that those software requirements related to safety have been implemented correctly, and as usual this has two components:
    • showing that the code implements the requirements (verification - we've built the right thing)
    • showing the code is well behaved under all circumstances (validation - we've built the thing right)
    If you are doing full formal semantic verification, the second step is unnecessary, as the semantic proof will consider all possible combinations of input and state. However, in practice formal proof is so onerous that its almost never done. This means that verification is based on testing, which no matter how thorough, is still based on sampling. There is an implied belief that the digital system will behave continuously, even though its known that this isn't true (a good few years ago an early home computer had an implementation of BASIC that had an integer ABS functions that worked perfectly except for ABS(-32768) which gave -32768  and it wasn't because it was limited to 16-bits, ABS(-32769) gave 32769 etc).

    The validation part aims to improve the (albeit flawed) belief in contiguous behaviour by:
    • checking that any constraints imposed by the language are respected
    • any deviations from arithmetic logic are identified (i.e. flagging where underflow, overflow, truncation, wraparound or loss of precision may occur)
    This is the domain of MISRA and JSF++  checking that the code will behave sensibly, without knowledge of what it should be doing.

    To get back to the original discussion, it is staggeringly naive to claim that 'I have a safe system, because I've used a certified OS kernel'.  I'm sure you weren't suggesting that, but I have seen companies try it. What the certified kernel (or any other architectural component) buys you is that someone has done the verification and validation activities on that component, so you can be reasonably confident that that component will behave as advertised - its a level of detail your project doesn't have to look into (though you may want to audit the quality of the certification evidence).

    As I read your original message you are asking 'why can't a wide user base be accepted as evidence of correctness?'  The short answer is, do you have any evidence of what features of the component the users are using and in what combination? Is my project about to use some combination of features in an inventive manner that no-one has previously tried, so the wide user base provides no evidence that it will work  (again a good few years ago, colleagues of mine were writing a compiler for a VAX and traced a bug to a particular instruction in the VAX instruction set that had an error in its implementation. No DEC product or other customer had ever used this instruction.  BTW, DEC's solution was to remove it from the instruction set)

    Hope this helps

           Clive
           LDRA Inc.

    On Thu, Nov 22, 2018 at 9:24 AM Paul Sherwood <paul.sherwood@...> wrote:
    Hi again...
    >>> The question is:-
    >>>
    >>> As Linux is monolithic, already written  (with minimal
    >>> requirements/design
    >>> docs) and not to any coding standard
    >>> How would the world go about making a Certifiable Linux?
    >
    >>> Is it possible?

    Sadly most of the followon discussion seems to have stayed only on
    systemsafetylist.org [1] which rather reduces its impact IMO.

    I cross-posted in the hope that knowledge from the safety community
    could be usefully shared with other communities who are (for better or
    worse) considering and in some cases already using Linux in
    safety-critical systems. For example Linux Foundation is actively
    soliciting contributors expressly for an initiative to establish how
    best to support safety scenarios, as discussed at ELCE [2] with
    contributors from OSADL (e.g. [3]) and others.

    Perhaps I'm being stupid but it's still unclear to me, after the
    discussion about existing certificates, whether the 'pre-certification'
    approach is justifiable at all, for **any** software, not just Linux.

    As I understand it, for any particular project/system/service we need to
    define safety requirements, and safety architecture. From that we need
    to establish constraints and required properties and behaviours of
    chosen architecture components (including OS components). On that basis
    it seems to me that we must always prepare a specific argument for an
    actual system, and cannot safely claim that any generic
    pre-certification fits our use-case?

    Please could someone from systemsafetylist.org reply-all and spell it
    out, preferably without referring to standards and without triggering a
    lot of controversy?

    br
    Paul

    [1] http://systemsafetylist.org/4310.htm
    [2]
    https://www.osadl.org/Linux-in-Safety-Critical-Systems-Summit.lfsummit-elce-safety.0.html
    [3]
    https://events.linuxfoundation.org/wp-content/uploads/2017/12/Collaborate-on-Linux-for-Use-in-Safety-Critical-Systems-Lukas-Bulwahn-BMW-Car-IT-GmbH-1.pdf


    _______________________________________________
    C-safe-secure-studygroup mailing list
    C-safe-secure-studygroup@...
    https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup


    Re: [SystemSafety] Critical systems Linux

    Paul Sherwood
     

    Hi again...
    The question is:-
    As Linux is monolithic, already written (with minimal requirements/design
    docs) and not to any coding standard
    How would the world go about making a Certifiable Linux?
    Is it possible?
    Sadly most of the followon discussion seems to have stayed only on systemsafetylist.org [1] which rather reduces its impact IMO.

    I cross-posted in the hope that knowledge from the safety community could be usefully shared with other communities who are (for better or worse) considering and in some cases already using Linux in safety-critical systems. For example Linux Foundation is actively soliciting contributors expressly for an initiative to establish how best to support safety scenarios, as discussed at ELCE [2] with contributors from OSADL (e.g. [3]) and others.

    Perhaps I'm being stupid but it's still unclear to me, after the discussion about existing certificates, whether the 'pre-certification' approach is justifiable at all, for **any** software, not just Linux.

    As I understand it, for any particular project/system/service we need to define safety requirements, and safety architecture. From that we need to establish constraints and required properties and behaviours of chosen architecture components (including OS components). On that basis it seems to me that we must always prepare a specific argument for an actual system, and cannot safely claim that any generic pre-certification fits our use-case?

    Please could someone from systemsafetylist.org reply-all and spell it out, preferably without referring to standards and without triggering a lot of controversy?

    br
    Paul

    [1] http://systemsafetylist.org/4310.htm
    [2] https://www.osadl.org/Linux-in-Safety-Critical-Systems-Summit.lfsummit-elce-safety.0.html
    [3] https://events.linuxfoundation.org/wp-content/uploads/2017/12/Collaborate-on-Linux-for-Use-in-Safety-Critical-Systems-Lukas-Bulwahn-BMW-Car-IT-GmbH-1.pdf


    Re: CIP IRC weekly meeting today

    Daniel Sangorrin <daniel.sangorrin@...>
     

    Hi SZ,

    I won't be able to attend the meeting today.
    I just sent a few e-mails for the CIP Software update workgroup and the CIP Core workgroup on the members list.
    I want to continue that conversation on the members list for now, before we start development.

    Thanks,
    Daniel

    -----Original Message-----
    From: cip-dev-bounces@...
    <cip-dev-bounces@...> On Behalf Of SZ Lin (林上智)
    Sent: Thursday, November 22, 2018 1:42 PM
    To: cip-dev@...
    Subject: [cip-dev] CIP IRC weekly meeting today

    Hi All,

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

    *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from first
    week of Nov. according F2F meeting discussion in ELCE.*

    US-West US-East UK DE TW JP
    02:00 05:00 09:00 10:00 17:00 18:00

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

    Agenda:
    * AI review
    - #action Make sure armhf is available in Debian 10 (or not)
    - #action Daniel will send cip-core questions to cip-members ML

    * Kernel maintenance updates
    * Kernel testing
    * Software update
    * CIP Core
    * AOB

    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,

    SZ Lin

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


    CIP IRC weekly meeting today

    SZ Lin (林上智) <SZ.Lin@...>
     

    Hi All,

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

    *Please note that IRC meeting was rescheduled to 18:00 (JST) starting from first week of Nov. according F2F meeting discussion in ELCE.*

    US-West US-East UK DE TW JP
    02:00 05:00 09:00 10:00 17:00 18:00

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

    Agenda:
    * AI review
    - #action Make sure armhf is available in Debian 10 (or not)
    - #action Daniel will send cip-core questions to cip-members ML

    * Kernel maintenance updates
    * Kernel testing
    * Software update
    * CIP Core
    * AOB

    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,

    SZ Lin


    Re: FW: [Lava-users] Git authentication

    Daniel Sangorrin <daniel.sangorrin@...>
     

    Good to know, thank you Chris.

    -----Original Message-----
    From: cip-dev-bounces@...
    <cip-dev-bounces@...> On Behalf Of Chris Paterson
    Sent: Tuesday, November 20, 2018 8:54 PM
    To: cip-dev@...
    Subject: [cip-dev] FW: [Lava-users] Git authentication

    Hello all,

    It was asked last week about if it is possible to keep jobs secret in the CIP LAVA test
    setup.

    Test results/definitions can indeed be kept private, either on an individual or group
    bases.
    https://lava.ciplatform.org/static/docs/v2/glossary.html#term-visibility

    If a test job is kept private it is also possible to share 'secret' information with the
    board. For example, a private git repository.
    https://lava.ciplatform.org/static/docs/v2/publishing-artifacts.html?highlight=sec
    rets

    Please see the mail below for more information.

    Kind regards, Chris

    -----Original Message-----
    From: Lava-users <lava-users-bounces@...> On Behalf Of
    Milosz Wasilewski
    Sent: 20 November 2018 10:46
    To: axel.lebourhis@...
    Cc: lava-users@...
    Subject: Re: [Lava-users] Git authentication

    On Tue, 20 Nov 2018 at 10:42, Axel Lebourhis <axel.lebourhis@...> wrote:

    Hi everyone,

    Is it possible to handle git authentication in a test job ?
    I need LAVA to clone a repo that can't be set to public,
    and obviously it won't work because of the authentication step.
    So is it possible to specify a password or a token ?
    You can use 'secrets' section in the job definition. Docs here:
    https://master.lavasoftware.org/static/docs/v2/publishing-artifacts.html?highligh
    t=secrets

    It might be also a good idea to limit access to the job to user or
    group so the password doesn't leak. It has to be plain text
    unfortunately.

    milosz

    _______________________________________________
    Lava-users mailing list
    Lava-users@...
    https://lists.lavasoftware.org/mailman/listinfo/lava-users
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Re: [SystemSafety] Critical systems Linux

    Paul Sherwood
     

    Now to attempt to answer the question...

    On 2018-11-20 18:45, Paul Sherwood wrote:
    The question is:-
    As Linux is monolithic, already written (with minimal requirements/design
    docs) and not to any coding standard
    How would the world go about making a Certifiable Linux?
    Is it possible?
    Some initiatives have already started down this road, for example SIL2LINUXMP (in cc)

    But my personal perspective is

    1) it may be the the certifications themselves are inappropriate. It's far from clear to me that the current standards are fit for purpose.

    2) there are many cases of folks retrofitting documentation to support compliance with standards, so perhaps that would be a feasible thing to attempt (although there is far too much code in the Linux kernel and associated FOSS tooling and userland components to make this something which could be achieved in a short time)

    3) if we could establish justifiable concrete improvements to make in Linux (and the tools, and the userland), we could hope to persuade the upstreams to make them, or accept our patches.

    4) we could construct new software to meet the ABI commitments of Linux (and other components) while adhering to some specific standards and/or processes, but I'm unconvinced this could be achieved in a time/cost-effective way.

    And the question I asked: why do it at all when there are plenty of other
    POSIX Compliant RTOS and OS out there that have full Safety Certification to
    61508 SIL3 and Do178 etc.?
    My understanding is that existing certified RTOS/OS tend to be microkernels with limited functionality, limited hardware support, and performance limitations for some usecases. I'd be happy to be wrong, and no-doubt advocates of some of those technologies can explain the reality by return.

    br
    Paul

    8441 - 8460 of 10124