Date   

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


    Re: [SystemSafety] Critical systems Linux

    Paul Sherwood
     

    On 2018-11-20 17:40, Chris Hills wrote:
    A subversion of the thread to answer one of the points raised by Paul and
    almost every Linux aficionado

    -----Original Message-----
    bielefeld.de] On Behalf Of Paul Sherwood
    Sent: Sunday, November 4, 2018 8:54 PM
    One anti-pattern I've grown a bit tired of is people choosing a
    micro-kernel instead of Linux, because of the notional 'safety cert',
    and then having to implement tons of custom software in attempting to
    match off-the-shelf Linux functionality or performance. When application
    of the standards leads to "develop new, from scratch" instead of using
    existing code which is widely used and known to be reliable, something
    is clearly weird imo.
    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?
    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.?
    While systemsafety may be the leading community for public discussion around systems (and software) safety, it is not the only ML that has an interest in this topic so I'm cross-posting to some other (including Linux) lists in the hope that we may see wider discussion and contribution.


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

    Jan Kiszka
     

    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.

    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

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


    FW: [Lava-users] Git authentication

    Chris Paterson
     

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

    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?highlight=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


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

    Nobuhiro Iwamatsu <nobuhiro.iwamatsu@...>
     

    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

    Best regards,
    Nobuhiro



    Jan

    #action Daniel will send cip-core questions to cip-members ML

    SZ Lin, Moxa
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev


    Re: List of patches that failed to apply to 4.4-stable

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

    Hi,

    On Monday, 19 November 2018 16:53:05 WET Daniel Wagner wrote:
    Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
    It turns out that some of the patches in the "to apply" list were already there applied.

    I have updated our wiki page accordingly
    https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches

    For the curious minds, you can find my (dirty) script attached to this e-mail.
    If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.

    @Daniel W. is the above possible, based on your experience with Gitlab?
    I don't think you can update a .md file via gitlab-ci. Though there is
    GitLab pages which seems to be the thing for creating documentation via
    a CI/CD job:

    https://docs.gitlab.com/ee/user/project/pages/
    There are SSGs that digest .md

    https://about.gitlab.com/2016/06/10/ssg-overview-gitlab-pages-part-2/

    this way the report can also be visualized not just as a static page but also as a repo file, like a normal wiki page. In any case, the format of the report is not a key point. HTML alone would work fine too, I guess.

    I assume you agree with the approach in general. Thanks for the response.

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


    Re: List of patches that failed to apply to 4.4-stable

    Daniel Wagner <daniel.wagner@...>
     

    Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
    It turns out that some of the patches in the "to apply" list were already there applied.

    I have updated our wiki page accordingly
    https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches

    For the curious minds, you can find my (dirty) script attached to this e-mail.
    If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.

    @Daniel W. is the above possible, based on your experience with Gitlab?
    I don't think you can update a .md file via gitlab-ci. Though there is
    GitLab pages which seems to be the thing for creating documentation via
    a CI/CD job:

    https://docs.gitlab.com/ee/user/project/pages/


    Re: List of patches that failed to apply to 4.4-stable

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

    Hi,

    On Friday, 16 November 2018 06:16:31 WET Daniel Sangorrin wrote:
    To kernel team,

    @SZLin: thanks for creating a page on the wiki just for that.

    Yesterday, I checked the patches in my "failed to apply to 4.4-stable" list against the actual git repository using a short python script.
    It turns out that some of the patches in the "to apply" list were already there applied.

    I have updated our wiki page accordingly
    https://wiki.linuxfoundation.org/civilinfrastructureplatform/linux-4.4-failed-patches

    For the curious minds, you can find my (dirty) script attached to this e-mail.
    If you can put the patches list as a repo on gitlab, and since the target repo is already being mirrored, I wonder if we can create a job that executes the script when the origin list gets updated. We can create a notification with the outcome to our testing mailing list. This way we just need to focus on having the origin in shape. If we add to this a way to parser the outcome in .md format and published as result in gitlab when the job "succeeds", we significantly reduce the effort associated to the wiki page.

    @Daniel W. is the above possible, based on your experience with Gitlab?

    Best Regards


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


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

    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?

    Jan

    #action Daniel will send cip-core questions to cip-members ML
    SZ Lin, Moxa
    _______________________________________________
    cip-dev mailing list
    cip-dev@...
    https://lists.cip-project.org/mailman/listinfo/cip-dev
    --
    Siemens AG, Corporate Technology, CT RDA IOT SES-DE
    Corporate Competence Center Embedded Linux


    CIP-dev IRC weekly meeting log: week 46

    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-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
    #action Daniel will send cip-core questions to cip-members ML

    SZ Lin, Moxa


    [Git][cip-project/cip-kernel/cip-kernel-sec][master] 3 commits: webview: Display {intrdoduced, fixed}-by value of 'never' properly

    Agustin Benito Bethencourt
     

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

    Commits:

    • ce82cf92
      by Ben Hutchings at 2018-11-18T21:33:27Z
      webview: Display {intrdoduced,fixed}-by value of 'never' properly
      
    • 770a43fa
      by Ben Hutchings at 2018-11-18T21:48:44Z
      webview: Move fixed/introduced commit lists into status on issue page
      
    • 606cb07e
      by Ben Hutchings at 2018-11-18T21:50:54Z
      webview: Use green/red colouring for status background rather than text
      

    2 changed files:

    Changes:

  • scripts/templates/issue.html
    ... ... @@ -71,36 +71,35 @@
    71 71
         </td>
    
    72 72
       </tr>
    
    73 73
       {% endif %}
    
    74
    -  {% if issue['introduced-by'] %}
    
    75 74
       <tr>
    
    76
    -    <th rowspan={{ issue['introduced-by']|length }}>Introduced by</th><
     /span>
    
    77
    -    {% for branch in issue['introduced-by'] %}
    
    75
    +    <th rowspan={{ branches|length }}>Status</th>
    
    76
    +    {% for name, affected in branches %}
    
    78 77
         <th>
    
    79
    -      {{ branch }}
    
    78
    +      <a href="/branch/{{ name }}/">{{ name }}</a>
    
    80 79
         </th>
    
    81 80
         <td>
    
    82
    -      {% for commit in issue['introduced-by'][branch] %}
    
    81
    +      {% if not affected %}
    
    82
    +      {% if issue['fixed-by'] and issue['fixed-by'][name] and issue['fixed-by'][name] != 'never' %}
    
    83
    +      <span class="good">fixed</span> by
    
    84
    +      {% for commit in issue['fixed-by'][name] %}
    
    83 85
           <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id={{ commit }}">{{ commit[:12] }}</a>{% if not loop.last %},{% endif %}
    
    84 86
           {% endfor %}
    
    85
    -    </td>
    
    86
    -    {% if not loop.last %}
    
    87
    -  </tr>
    
    88
    -  <tr>
    
    89
    -    {% endif %}
    
    90
    -    {% endfor %}
    
    91
    -  </tr>
    
    92
    -  {% endif %}
    
    93
    -  {% if issue['fixed-by'] %}
    
    94
    -  <tr>
    
    95
    -    <th rowspan={{ issue['fixed-by']|length }}>Fixed by</th>
    
    96
    -    {% for branch in issue['fixed-by'] %}
    
    97
    -    <th>
    
    98
    -      {{ branch }}
    
    99
    -    </th>
    
    100
    -    <td>
    
    101
    -      {% for commit in issue['fixed-by'][branch] %}
    
    87
    +      {% else %}
    
    88
    +      <span class="good">never affected</span>
    
    89
    +      {% endif %}
    
    90
    +      {% else %}
    
    91
    +      {% if issue.ignore and (issue.ignore.all or issue.ignore[name]) %}
    
    92
    +      <span class="ignored">ignored</span>
    
    93
    +      {% else %}
    
    94
    +      <span class="bad">vulnerable</span>
    
    95
    +      {% endif %}
    
    96
    +      {% if issue['introduced-by'] and issue['introduced-by'][name] and issue['introduced-by'][name] != 'never' %}
    
    97
    +      - introduced by
    
    98
    +      {% for commit in issue['introduced-by'][name] %}
    
    102 99
           <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit?id={{ commit }}">{{ commit[:12] }}</a>{% if not loop.last %},{% endif %}
    
    103 100
           {% endfor %}
    
    101
    +      {% endif %}
    
    102
    +      {% endif %}
    
    104 103
         </td>
    
    105 104
         {% if not loop.last %}
    
    106 105
       </tr>
    
    ... ... @@ -108,7 +107,6 @@
    108 107
         {% endif %}
    
    109 108
         {% endfor %}
    
    110 109
       </tr>
    
    111
    -  {% endif %}
    
    112 110
       {% if issue['fix-depends-on'] %}
    
    113 111
       <tr>
    
    114 112
         <th>Fix depends on</th>
    
    ... ... @@ -122,26 +120,4 @@
    122 120
         </td>
    
    123 121
       </tr>
    
    124 122
       {% endif %}
    
    125
    -  <tr>
    
    126
    -    <th rowspan={{ branches|length }}>Status</th>
    
    127
    -    {% for name, affected in branches %}
    
    128
    -    <th>
    
    129
    -      <a href="/branch/{{ name }}/">{{ name }}</a>
    
    130
    -    </th>
    
    131
    -    <td>
    
    132
    -      {% if not affected %}
    
    133
    -      {# Currently we don't distinguish between never-affected or fixed #}
    
    134
    -      <span class="good">not affected</span>
    
    135
    -      {% elif issue.ignore and (issue.ignore.all or issue.ignore[name]) %}
    
    136
    -      <span class="ignored">ignored</span>
    
    137
    -      {% else %}
    
    138
    -      <span class="bad">vulnerable</span>
    
    139
    -      {% endif %}
    
    140
    -    </td>
    
    141
    -    {% if not loop.last %}
    
    142
    -  </tr>
    
    143
    -  <tr>
    
    144
    -    {% endif %}
    
    145
    -    {% endfor %}
    
    146
    -  </tr>
    
    147 123
     </table>

  • scripts/templates/style.css
    ... ... @@ -20,10 +20,10 @@ body {
    20 20
     }
    
    21 21
     
    
    22 22
     .good {
    
    23
    -    color: #33cc33;
    
    23
    +    background-color: #40ff40;
    
    24 24
     }
    
    25 25
     .bad {
    
    26
    -    color: #ff0000;
    
    26
    +    background-color: #ff4040;
    
    27 27
     }
    
    28 28
     
    
    29 29
     table {
    

  • 8021 - 8040 of 9694