Date   

Re: Create development branch for 4.19.y

Daniel Wagner <wagi@...>
 

I've started to work on the -rt flavor CIP tree and imported the corresponding preempt-rt patches. Before I can upload the cip-rt patches I need a tag to base it on. Wouldn't you mind to add a -cip1 tag now?
Ignore it. Just realize the is the v4.19.13-cip1 tag I was looking for. Hmm, maybe be my local tree was not up to date.

Thanks,
Daniel


Re: Create development branch for 4.19.y

Daniel Wagner <wagi@...>
 

Hi Nobuhiro,

On 11/12/18 2:58 PM, Nobuhiro Iwamatsu wrote:
If you have a patch for CIP kernel 4.19.y, please post it on the base.
I've started to work on the -rt flavor CIP tree and imported the corresponding preempt-rt patches. Before I can upload the cip-rt patches I need a tag to base it on. Wouldn't you mind to add a -cip1 tag now?

Thanks,
Daniel


[ANNOUNCE] 4.4.166-cip29-rt21

Daniel Wagner <wagi@...>
 

Hello CIP RT Folks!

I'm pleased to announce the 4.4.166-cip29-rt21 stable release.

You can get this release via the git tree at:

git://git.kernel.org/pub/scm/linux/kernel/git/cip/linux-cip.git

branch: linux-4.4.y-cip-rt
Head SHA1: 616268e69203813b01644ebb971cbf1957db7d60

Enjoy!
Daniel


[Git][cip-project/cip-kernel/cip-kernel-sec][master] 2 commits: Import more data

Agustin Benito Bethencourt
 


[Git][cip-project/cip-kernel/cip-kernel-sec][master] 4 commits: The Ubuntu CVE tracker migrated from bzr to git. Use new url in import_ubuntu.py script.

Agustin Benito Bethencourt
 

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

Commits:

  • a3a90572
    by Christophe Kassabji at 2018-08-02T15:28:47Z
    The Ubuntu CVE tracker migrated from bzr to git. Use new url in import_ubuntu.py script.
  • 4ffab6a9
    by Ben Hutchings at 2019-01-09T17:02:42Z
    Merge branch 'master' of https://gitlab.com/ckassabji/cip-kernel-sec
    
  • 4062b400
    by Ben Hutchings at 2019-01-09T17:06:37Z
    Clean up remnants of Bazaar-NG
    
    * scripts/import_ubuntu.py: Delete local Bazaar-NG repository if present
    * README.md: Drop it from requirements
    
  • cf3ca110
    by Ben Hutchings at 2019-01-09T17:11:56Z
    Import data from Ubuntu
    
    But override the fixed-by field for CVE-2016-10723, as the commit
    they recorded is not a complete fix.
    

30 changed files:

The diff was not included because it is too large.


Re: [RFC] isar-cip-core

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Monday, January 7, 2019 3:59 PM
To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
Subject: Re: [cip-dev] [RFC] isar-cip-core



-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Monday, January 7, 2019 3:59 PM
To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
Subject: Re: [cip-dev] [RFC] isar-cip-core

On 07.01.19 07:45, Daniel Sangorrin wrote:
-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Monday, January 7, 2019 2:41 PM
To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
Subject: Re: [cip-dev] [RFC] isar-cip-core

Hi Daniel,

On 07.01.19 01:30, Daniel Sangorrin wrote:
Hi Jan,

Thanks for uploading isar-cip-core.

As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder
with
the intention of adding "isar" and other tools' metadata at the same folder level.

cip-core/ <-- git repo
deby/ <-- deby metadata
isar/ <-- isar metadata
eid/ <-- eid metadata

[Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.

I think that having all of the metadata on the same repository can be good for communication. For
example,
after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder
that
should be applied to Deby's metadata as well.

I agree that shared data like reference configs should ideally be stored in one
place. That could be solved by having a single repos for all build systems or by
sticking those artifacts into a separate repo. We already have
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the
configs of the reference boards there?
I said "communication" (like in a monorepo) rather than shared data, because each build tool has different
methods to store that shared data. In the case of a kernel config, it will probably work fine, but there is always
a possibility that we need to add some tuning on the recipe's metadata.

When it comes to pure communication, the mailing list is a better place. We
could route all cip-core patches through it (rather than splitting up the work
in isolated MRs on gitlab).


Another possibility is to use gitlab groups/subgroups in this way:

cip-core/ <-- group
tiny/ <-- subgroup
deby <-- git repo
generic/ <-- subgroup
isar <-- git repo

I don't have enough permissions to create groups and subgroups under cip-project though (that's the
reason
I used the folder approach).
I do. If we agree on the group approach, we need to rename the existing cip-core
repo first, and flatten its folder structure. Then I can create the cip-core
group as well as the tiny/generic subgroups and move the repo.

Later on, we can factor out the kernel configs. Do you see other shared data?
Well, one could be the list of packages for each profile. However, as I mention above it will be hard to share
exactly the same files.

Yes, sharing the package list 1:1 will only work if the tiny profile follows the
standard Debian binary packaging structure - does/will it?
Not necessarily.
For example, Deby follows the Open Embedded structure as far as I know.

Thanks,
Daniel



Which way would you prefer?
I'm leaning towards separate repos.
OK, then let's analyze the pros and cons and decide today at the TSC meeting.
Fine with me.

Jan

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


Re: [RFC] isar-cip-core

Jan Kiszka
 

On 07.01.19 07:45, Daniel Sangorrin wrote:
-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Monday, January 7, 2019 2:41 PM
To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
Subject: Re: [cip-dev] [RFC] isar-cip-core

Hi Daniel,

On 07.01.19 01:30, Daniel Sangorrin wrote:
Hi Jan,

Thanks for uploading isar-cip-core.

As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder with
the intention of adding "isar" and other tools' metadata at the same folder level.

cip-core/ <-- git repo
deby/ <-- deby metadata
isar/ <-- isar metadata
eid/ <-- eid metadata

[Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.

I think that having all of the metadata on the same repository can be good for communication. For example,
after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder that
should be applied to Deby's metadata as well.

I agree that shared data like reference configs should ideally be stored in one
place. That could be solved by having a single repos for all build systems or by
sticking those artifacts into a separate repo. We already have
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the
configs of the reference boards there?
I said "communication" (like in a monorepo) rather than shared data, because each build tool has different methods to store that shared data. In the case of a kernel config, it will probably work fine, but there is always a possibility that we need to add some tuning on the recipe's metadata.
When it comes to pure communication, the mailing list is a better place. We could route all cip-core patches through it (rather than splitting up the work in isolated MRs on gitlab).


Another possibility is to use gitlab groups/subgroups in this way:

cip-core/ <-- group
tiny/ <-- subgroup
deby <-- git repo
generic/ <-- subgroup
isar <-- git repo

I don't have enough permissions to create groups and subgroups under cip-project though (that's the reason
I used the folder approach).
I do. If we agree on the group approach, we need to rename the existing cip-core
repo first, and flatten its folder structure. Then I can create the cip-core
group as well as the tiny/generic subgroups and move the repo.

Later on, we can factor out the kernel configs. Do you see other shared data?
Well, one could be the list of packages for each profile. However, as I mention above it will be hard to share exactly the same files.
Yes, sharing the package list 1:1 will only work if the tiny profile follows the standard Debian binary packaging structure - does/will it?


Which way would you prefer?
I'm leaning towards separate repos.
OK, then let's analyze the pros and cons and decide today at the TSC meeting.
Fine with me.

Jan

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


Re: [RFC] isar-cip-core

Daniel Sangorrin <daniel.sangorrin@...>
 

-----Original Message-----
From: Jan Kiszka <jan.kiszka@...>
Sent: Monday, January 7, 2019 2:41 PM
To: Daniel Sangorrin <daniel.sangorrin@...>; 'cip-dev' <cip-dev@...>
Subject: Re: [cip-dev] [RFC] isar-cip-core

Hi Daniel,

On 07.01.19 01:30, Daniel Sangorrin wrote:
Hi Jan,

Thanks for uploading isar-cip-core.

As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder with
the intention of adding "isar" and other tools' metadata at the same folder level.

cip-core/ <-- git repo
deby/ <-- deby metadata
isar/ <-- isar metadata
eid/ <-- eid metadata

[Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.

I think that having all of the metadata on the same repository can be good for communication. For example,
after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder that
should be applied to Deby's metadata as well.

I agree that shared data like reference configs should ideally be stored in one
place. That could be solved by having a single repos for all build systems or by
sticking those artifacts into a separate repo. We already have
https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the
configs of the reference boards there?
I said "communication" (like in a monorepo) rather than shared data, because each build tool has different methods to store that shared data. In the case of a kernel config, it will probably work fine, but there is always a possibility that we need to add some tuning on the recipe's metadata.

Another possibility is to use gitlab groups/subgroups in this way:

cip-core/ <-- group
tiny/ <-- subgroup
deby <-- git repo
generic/ <-- subgroup
isar <-- git repo

I don't have enough permissions to create groups and subgroups under cip-project though (that's the reason
I used the folder approach).
I do. If we agree on the group approach, we need to rename the existing cip-core
repo first, and flatten its folder structure. Then I can create the cip-core
group as well as the tiny/generic subgroups and move the repo.

Later on, we can factor out the kernel configs. Do you see other shared data?
Well, one could be the list of packages for each profile. However, as I mention above it will be hard to share exactly the same files.

Which way would you prefer?
I'm leaning towards separate repos.
OK, then let's analyze the pros and cons and decide today at the TSC meeting.

Thanks,
Daniel



Jan


Thanks,
Daniel

[1] https://gitlab.com/cip-project/cip-core/issues/2
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [RFC] isar-cip-core

Jan Kiszka
 

Hi Daniel,

On 07.01.19 01:30, Daniel Sangorrin wrote:
Hi Jan,
Thanks for uploading isar-cip-core.
As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder with the intention of adding "isar" and other tools' metadata at the same folder level.
cip-core/ <-- git repo
deby/ <-- deby metadata
isar/ <-- isar metadata
eid/ <-- eid metadata
[Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.
I think that having all of the metadata on the same repository can be good for communication. For example, after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder that should be applied to Deby's metadata as well.
I agree that shared data like reference configs should ideally be stored in one place. That could be solved by having a single repos for all build systems or by sticking those artifacts into a separate repo. We already have https://gitlab.com/cip-project/cip-kernel/cip-kernel-config - maybe add the configs of the reference boards there?

Another possibility is to use gitlab groups/subgroups in this way:
cip-core/ <-- group
tiny/ <-- subgroup
deby <-- git repo
generic/ <-- subgroup
isar <-- git repo
I don't have enough permissions to create groups and subgroups under cip-project though (that's the reason I used the folder approach).
I do. If we agree on the group approach, we need to rename the existing cip-core repo first, and flatten its folder structure. Then I can create the cip-core group as well as the tiny/generic subgroups and move the repo.

Later on, we can factor out the kernel configs. Do you see other shared data?

Which way would you prefer?
I'm leaning towards separate repos.

Jan

Thanks,
Daniel
[1] https://gitlab.com/cip-project/cip-core/issues/2
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux


Re: [RFC] isar-cip-core

Daniel Sangorrin <daniel.sangorrin@...>
 

Hi Jan,

Thanks for uploading isar-cip-core.

As you noticed[1], https://gitlab.com/cip-project/cip-core/ contains a folder "deby". I created that folder with the intention of adding "isar" and other tools' metadata at the same folder level.

cip-core/ <-- git repo
deby/ <-- deby metadata
isar/ <-- isar metadata
eid/ <-- eid metadata

[Note] Now that we have profiles (tiny and generic) we could add an extra folder for them.

I think that having all of the metadata on the same repository can be good for communication. For example, after a git-pull I might notice that you updated certain kernel configuration values under the "isar" folder that should be applied to Deby's metadata as well.

Another possibility is to use gitlab groups/subgroups in this way:

cip-core/ <-- group
tiny/ <-- subgroup
deby <-- git repo
generic/ <-- subgroup
isar <-- git repo

I don't have enough permissions to create groups and subgroups under cip-project though (that's the reason I used the folder approach).

Which way would you prefer?

Thanks,
Daniel

[1] https://gitlab.com/cip-project/cip-core/issues/2

-----Original Message-----
From: cip-dev-bounces@... <cip-dev-bounces@...> On Behalf Of Jan Kiszka
Sent: Friday, January 4, 2019 3:03 AM
To: cip-dev <cip-dev@...>
Subject: [cip-dev] [RFC] isar-cip-core

Hi,

happy new year to everyone!

New year, new project: I've started isar-cip-core in our incubating area, see
https://gitlab.com/cip-playground/isar-cip-core.

It's currently only generating an SD card image for the BeagleBone Black, but
that can easily be extended. The idea is to model our generic profile CIP Core
this way, producing images that contain all supported packages and can then be
used for testing, evaluation etc.

README is still missing, will write one tomorrow:

# wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker
# chmod a+x kas-docker
# ./kas-docker --isar build kas.yml:board-bbb.yml

or

# ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml

for the RT variant.

Looking forward to feedback!

Jan

--
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: [RFC] isar-cip-core

Jan Kiszka
 

On 03.01.19 19:03, Jan Kiszka wrote:
Hi,
happy new year to everyone!
New year, new project: I've started isar-cip-core in our incubating area, see https://gitlab.com/cip-playground/isar-cip-core.
It's currently only generating an SD card image for the BeagleBone Black, but that can easily be extended. The idea is to model our generic profile CIP Core this way, producing images that contain all supported packages and can then be used for testing, evaluation etc.
README is still missing, will write one tomorrow:
# wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker
# chmod a+x kas-docker
# ./kas-docker --isar build kas.yml:board-bbb.yml
or
# ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml
for the RT variant.
Looking forward to feedback!
Jan
README has been added, also a qemu-amd64 target together with a starter script and a target for the SIMATIC IPC227E.

Jan

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


[RFC] isar-cip-core

Jan Kiszka
 

Hi,

happy new year to everyone!

New year, new project: I've started isar-cip-core in our incubating area, see https://gitlab.com/cip-playground/isar-cip-core.

It's currently only generating an SD card image for the BeagleBone Black, but that can easily be extended. The idea is to model our generic profile CIP Core this way, producing images that contain all supported packages and can then be used for testing, evaluation etc.

README is still missing, will write one tomorrow:

# wget https://raw.githubusercontent.com/siemens/kas/master/kas-docker
# chmod a+x kas-docker
# ./kas-docker --isar build kas.yml:board-bbb.yml

or

# ./kas-docker --isar build kas.yml:board-bbb.yml:opt-rt.yml

for the RT variant.

Looking forward to feedback!

Jan

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


CIP IRC weekly meeting will be skipped this week

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

Hi all,

 

Happy new year 2019.

 

If no one has any objections, I would like to skip CIP kernel weekly meeting this week due to holidays.

 

Best regards,

 

SZ Lin, Moxa.


CIP IRC weekly meeting today

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

Hi All,

 

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

 

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

 

US-West US-East  UK    DE     TW     JP

02:00    05:00   09:00   10:00   17:00   18:00

 

Channel:

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

 

Agenda:

 

* Kernel maintenance updates

* Kernel testing

* CIP Core

* Software update

* AOB

 

The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting..

 

Best regards,

 

SZ Lin, Moxa.


CIP-dev IRC weekly meeting log: week 51

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

Hi,

 

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

 

https://irclogs.baserock.org/cip/%23cip.2018-12-20.log.html#t2018-12-20T09:00:06

 

SZ Lin, Moxa


Beaglebone Black thud kas-bbb-thud.yml script

Zoran
 

Hello to all,

I produced thud KAS script to do some dirty and quick bbb YOCTO rootfs
and kernel (4.19.7) production.

For this purpose I have enhanced Beaglebone Black sumo KAS script to
thud, to serve to the purpose.

If anybody needs it, please, find it attached (with meta-socketcan layer
addendum, which is my proprietary layer invention due to some work done
for automotive industry).

If you do not need meta-socketcan layer included as extras, just remove
these lines from the script:
  meta-socketcan:
    url: "https://github.com/ZoranStojsavljevic/meta-socketcan.git"
    refspec: 064d2fdf5b69e5c038aba225884c183b8e00f30b


Please, also do note that the script takes default variables, if they are not
explicitly specified.

Thank you,
Zoran
_______


CIP IRC weekly meeting today

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

Hi All,

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

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

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

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

Agenda:

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

The meeting will take 30 min although it can be extended to an hour if it makes sense and those involved in the topics can stay. Otherwise, the topic will be taken offline or in the next meeting..

Best regards,

SZ Lin, Moxa.


[ANNOUNCE] Linux kernel CVE tracker

Ben Hutchings <ben.hutchings@...>
 

As part of my work for the Civil Infrastructure Platform, I've been
tracking security issues in the kernel and trying to ensure that the
fixes are applied to stable branches as necessary.

The "kernel-sec" repository at
<https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec> contains
information about known issues and scripts to aid in maintaining and
viewing that information. Issues are identified by CVE ID and their
status is recorded for mainline and all live stable branches.

I import most of the information from distribution security trackers,
and from upstream commit references in stable branch commit messages.
Manual editing is needed mostly to correct errors in these sources, or
where the commits fixing an issue in a stable branch don't correspond
exactly to the commits fixing it in mainline.

I recently added a local web application that allows browsing the
status of all branches and issues, complete with links to references
and related commits. There is also a simple reporting script that
lists open issues for each branch.

If you're interested in security support for stable branches, please
take a look at this.

I would welcome merge requests to add to the issue data or to improve
the scripts.

Ben.

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


[Git][cip-project/cip-kernel/cip-kernel-sec][master] 4 commits: kernel_sec.branch: Create import directory before branches cache

Agustin Benito Bethencourt
 

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

Commits:

  • e77a4ade
    by Ben Hutchings at 2018-12-19T15:09:00Z
    kernel_sec.branch: Create import directory before branches cache
    
  • 10d08339
    by Ben Hutchings at 2018-12-19T15:54:55Z
    kernel_sec.issue: Explicitly use UTF-8 encoding for YAML files
    
    By default, the encoding is locale-dependent.
    
  • 5f62ad65
    by Ben Hutchings at 2018-12-19T15:59:17Z
    README.md: Document the need for a kernel git repository
    
  • 45b595b9
    by Ben Hutchings at 2018-12-19T16:03:20Z
    README.md: Document that import_ubuntu.py needs Bazaar-NG
    

3 changed files:

Changes:

  • README.md
    ... ... @@ -17,6 +17,11 @@ subdirectory. Supporting modules are in the `kernel_sec` subdirectory
    17 17
     beneath that.  They require PyYAML and html5lib (packaged in Debian as
    
    18 18
     python3-yaml and python3-html5lib).
    
    19 19
     
    
    20
    +Many scripts require access to a kernel git repository.  By default
    
    21
    +this is assumed to be in `../kernel`, with remotes named `torvalds`
    
    22
    +and `stable` for the mainline and stable repositories.  These can
    
    23
    +be overridden by command-line options.
    
    24
    +
    
    20 25
     * `scripts/import_debian.py` - import information from Debian's
    
    21 26
     `kernel_sec` project.  It includes all issues that Debian considers
    
    22 27
     active or that are already tracked here.
    
    ... ... @@ -26,6 +31,7 @@ active or that are already tracked here.
    26 31
     marked as affecting the 'linux' package and don't have the word
    
    27 32
     'Android' in the description, and that are either dated from the
    
    28 33
     current or previous year or that are already tracked here.
    
    34
    +It requires Bazaar-NG (bzr) to be installed and configured.
    
    29 35
     
    
    30 36
     * `scripts/import_stable.py` - import information about backports
    
    31 37
     to stable by reading the git commit logs.
    

  • scripts/kernel_sec/branch.py
    ... ... @@ -105,6 +105,7 @@ def get_live_stable_branches():
    105 105
                 return branches
    
    106 106
             raise
    
    107 107
     
    
    108
    +    os.makedirs('import', 0o777, exist_ok=True)
    
    108 109
         with open('import/branches.yml', 'w') as f:
    
    109 110
             yaml.safe_dump(branches, f)
    
    110 111
         return branches
    

  • scripts/kernel_sec/issue.py
    ... ... @@ -265,12 +265,12 @@ _IssueLoader.add_constructor('tag:yaml.org,2002:timestamp',
    265 265
     
    
    266 266
     
    
    267 267
     def load_filename(name):
    
    268
    -    with open(name) as f:
    
    268
    +    with open(name, 'r', encoding='utf-8') as f:
    
    269 269
             return yaml.load(f, Loader=_IssueLoader)
    
    270 270
     
    
    271 271
     
    
    272 272
     def save_filename(name, issue):
    
    273
    -    with open(name, 'w') as f:
    
    273
    +    with open(name, 'w', encoding='utf-8') as f:
    
    274 274
             yaml.dump(issue, f, Dumper=_IssueDumper)
    
    275 275
     
    
    276 276
     
    


  • [Git][cip-project/cip-kernel/cip-kernel-sec][master] kernel_sec.isssue: Fix sorting of 7-digit CVE IDs

    Agustin Benito Bethencourt
     

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

    Commits:

    • 9f9d7040
      by Ben Hutchings at 2018-12-18T20:45:55Z
      kernel_sec.isssue: Fix sorting of 7-digit CVE IDs
      
      DWF (Distributed Weakness Filing) assigns IDs with 7 "arbitrary digits"
      so we should pad shorter IDs accordingly.
      

    1 changed file:

    Changes:

  • scripts/kernel_sec/issue.py
    ... ... @@ -295,9 +295,9 @@ def save(cve_id, issue):
    295 295
     _cve_id_arbdig_re = re.compile(r'-(\d+)$')
    
    296 296
     
    
    297 297
     
    
    298
    -# Pad "arbitrary digits" to 6 digits so string comparison works
    
    298
    +# Pad "arbitrary digits" to 7 digits so string comparison works
    
    299 299
     def get_id_sort_key(cve_id):
    
    300
    -    return _cve_id_arbdig_re.sub(lambda m: '-%06d' % int(m.group(1)), cve_id)
    
    300
    +    return _cve_id_arbdig_re.sub(lambda m: '-%07d' % int(m.group(1)), cve_id)
    
    301 301
     
    
    302 302
     
    
    303 303
     def affects_branch(issue, branch, is_commit_in_branch):
    

  • 8421 - 8440 of 10158