Re: [yocto] CVEs and OSS info for nested dependencies
On Wed, Jul 31, 2024 at 1:28 PM Peter Marko via lists.yoctoproject.org wrote: > > > -Original Message- > > From: Steven Dorigotti > > Sent: Wednesday, July 31, 2024 13:20 > > To: Marko, Peter (ADV D EU SK BFS1) > > Cc: yocto@lists.yoctoproject.org > > Subject: Re: [yocto] CVEs and OSS info for nested dependencies > > > > > > > On 31 Jul 2024, at 10:21, Marko, Peter > wrote: > > > > Hello Peter, > > > > > This topic comes up from time to time. > > > > It’s nice to get confirmation, I was unable to find any traces of the > issue. > > > > > There was already a patch proposed for this: > > > https://lists.openembedded.org/g/openembedded- > > core/topic/101991269#msg189260 > > > https://lists.openembedded.org/g/openembedded- > > core/topic/102076964#msg189501 > > > > > > Maybe it wouldn't be that difficult to finish it, but it's possible > that it needs > > to get a bit broader to also update generated spdx > > > as there is ongoing activity to separate cve-check into offline tool > processing > > the spdx file. > > > > This does seems like a good start on the CVE reporting side. > > > > Whereas for SPDX, perhaps the “dummy dependency package” (e.g. nodejs- > > nghttp2) approach may be the simplest alternative even though it requires > > manual copying of license info/files and some extra maintenance overhead. > > How does this sound to you? > > I don't think that dummy dependencies are a good solution. > They will be forgotten to update and for recipes like node there will be > maybe hundereds of them. > (e.g. see any rust recipe how long they are, and that would be split to > that many files) > Having a variable which defines all vendored components in some form (e.g. > "type,name,version,cpe") looks much better. > > Some form of metadata without having to do a dummy recipe would be good. It would need to include the recipe name plus version (to re-use CPEs if they exist already) or a complete vendor/product/version if a new one. This is likely a little more complex for SPDX, because you should likely say which file in the source is from which package. This being said, with the external tooling it is also possible to generate the appropriate JSON. Merging the package list is not supported for now, but it is an easy thing to do. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63632): https://lists.yoctoproject.org/g/yocto/message/63632 Mute This Topic: https://lists.yoctoproject.org/mt/107642720/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVEs and OSS info for nested dependencies
On Wed, Jul 31, 2024 at 10:03 AM Steven Dorigotti via lists.yoctoproject.org wrote: > Hello, > > I think I have come across some limitations in CVE and OSS handling for > internal dependencies. > > As a practical example to make this clear, let’s take this CVE: > https://nvd.nist.gov/vuln/detail/CVE-2023-35945 > > which doesn’t show up in the cve-check report, and the nghttp2 dependency > is not listed in the license manifest file. > > The CVE is applicable to all versions of nghttp2 “Up to (excluding) > 1.55.1” which affects an internal dependency of nodejs. The latest > openembedded recipes are unaffected but Kirkstone uses node 16.20.2 and > nghttp2 1.47.0 which does seem affected. > > Can you confirm that there is currently no way to define CVE_PRODUCT / > CVE_VERSION pairs for nested package dependencies? Is this planned at all > for the future or do you have any suggestions here? > > Otherwise I’ll need to consider some kind of workaround, perhaps defining > N dummy/empty packages such as “nodejs-ngttp2” so that CVEs are detected > and complete manifest license info is generated. > > The same issue applies to many large projects such as Qt, which have many > nested/static (and at this stage hidden) dependencies. > > Thanks a lot in advance, > > Hello Steven, I can't find an envoy recipe in the database, so the response needs to be generic. If nghttp2 is a normal dependency (dependency to a different recipe), this will work just fine. The CVE entry for this vuln has nghttp2 well marked. However, if the nghttp2 code is just copied in, without a trace in the OE build system, then it's another story. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63626): https://lists.yoctoproject.org/g/yocto/message/63626 Mute This Topic: https://lists.yoctoproject.org/mt/107642720/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SPDX for dependency checks
On Wed, Jul 24, 2024 at 7:08 AM Tom Isaacson via lists.yoctoproject.org wrote: > We're using Kirkstone and wanted to take advantage of the SPDX support > to use for dependency checking. The two apps we have access to are: > 1. Github Dependabot > ( > https://docs.github.com/en/code-security/getting-started/dependabot-quickstart-guide > ) > 2. Mend (https://www.mend.io/) > > We generate the SPDX in a Github Action then tried uploading it using: > * https://github.com/marketplace/actions/spdx-dependency-submission-action > * https://pypi.org/project/mend-import-sbom/ > but so far we haven't been able to get it to work. Has anyone else tried > this? > > It will work if you submit individual SPDX files for packages (in most cases). The aggregation done by the YP is non-standard and tools have difficulties parsing it. Should be also better with SPDX3, but it looks like (from the documentation) that those two tools do not support 3.0 yet. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63566): https://lists.yoctoproject.org/g/yocto/message/63566 Mute This Topic: https://lists.yoctoproject.org/mt/107518802/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Dropbear and deprecated ssh-rsa issue
On Wed, Jun 19, 2024 at 7:04 PM Mehmet Fide via lists.yoctoproject.org wrote: > Yes, I believe I can do that. But there are couple of options, I'm not > sure which one to be followed: > 1. Replace rsa key with ecdsa and continue with ecdsa support only. (this > disables rsa mode) > 2. Keep rsa mode on and also activate ecdsa key next to it therefore they > can work side by side simultaneously > 3. ?? > Thanks for spotting this one! For master I would just drop RSA and add a big note to the migration notes for the next release. There are other breaking changes usually too. For LTS branches it would be good to enable ECDSA in addition to RSA at least. Steve, what do you think? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63371): https://lists.yoctoproject.org/g/yocto/message/63371 Mute This Topic: https://lists.yoctoproject.org/mt/106649419/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] CVE Scanners and Package Version
I will reply here to multiple issues raised in this thread. On Tue, Jan 2, 2024 at 10:46 PM Adrian Freihofer wrote: > > On Tue, 2024-01-02 at 09:24 +0200, Mikko Rapeli wrote: > > Hi, > > > > On Sat, Dec 23, 2023 at 02:47:36AM -0800, fabian.hanke via > > lists.yoctoproject.org wrote: > > > Hello Yocto community, > > > > > > we must provide a SBOM for our Yocto based product which will then > > > be used for (internal) CVE scanning by the security department. > > > Generating the base document in cycloneDX format is fairly easy > > > (thanks to the nature of Yocto). > > Our experts have also opted for CycloneDX. Is your CycloneDX generator > publicly available? > > > > Note that SBOM is mostly used for documenting SW components and their > > licenses. > > Obvious but needs to be made clear. > > I don't think that's true. > A SBOM should probably also list the CVE patches and provide > information about fixed CVEs. > I'm not sure about SPDX, but CycloneDX also addresses this use case: > https://cyclonedx.org/capabilities/vex/. > SPDX3 addresses this in a similar way as CycloneDX does. There's also the VEX way (like in OpenVEX) that is similar to both. The additional information that can/should be added is the "human" processing, for example stating that in *this configuration* the issues does not apply because XYZ. We have that partially in CVE_STATUS_* > > > > > > But we do not know how to include information about CVE patches for > > > each package in the document. Not providing these, will cause a lot > > > of “false” feedback on CVEs for specific versions which are already > > > patched (but version number did not change). > Yes, that's a real issue. > > > This problem was also mentioned a few days ago in the presentation > > > from David Reyna: https://youtu.be/PegU1G1bA80?t=1127. I like the > > > proposed solution of adding a vendor specific string to the package > > > version. But I'm still wondering: How would the CVE scanner vendor > > > know which CVEs are included in a yocto specific version and which > > > are not? > If the SBOM contains the information from CVE_STATUS_* variables and > the CVE scanner has access to the NIST database it should theoretically > work. As mentioned, the CVE information changes over time. The current SBOM specs allow to include it, but then this will require a periodic refresh. Personally I like more the approach of static SBOM plus a VEX-style file with the CVE sitation assessment for a given date. This allows also a possibility to have information WHO actually did that assessment. > > > > If the intention is to know CVE paching and analysis status of a > > product, then I'd use > > the yocto upstream tooling for this, cve-check.bbclass. SBOM and SPDX > > are tempting but not actually > > useful for CVE patching and analysis work, except when they show that > > a lot of old open source > > SW components are embedded into various binaries. > This works well from a developer's point of view, but not from an end > customer's or penetration tester's point of view. Many companies sell > products with a pre-installed Yocto-based firmware, but do not provide > the layers and bitbake with the firmware. It is likely that they will be in obligation to deliver that data in a few years' time frame. > > Such a SBOM would enable a user or a pen-tester to use a tool which > generates a CVE report from the SBOM and the current data from e.g. the > NIST database. This tool can run at any time and could be a generic > SBOM tool which is independent from Yocto. The NIST DB is dynamic, but > publicly available. The SBOM is static and provided with each firmware > release. > This kind of a work has been discussed already. If someone has funding available to make it happen, I will be interested to know about it. > > > > AFAIK, and I'd be happy to be proven wrong, SPDX and SBOM don't help > > matching SW component names > > and version strings so that comparison against CVE database > > information works. Only license names > > are standardized. > > I'm not sure what the current status is. But even if it's not > completely solved today, that doesn't mean it can't or shouldn't be > solved. The specifications are also open source. > The way to indicate that a given modified version has a fix for an issue is not toally solved today. Or, more precisely, it has multiple possible solutions. The discussion in this thread is in fact related to what we have in sessions about SRTools. Would you be willing to join? Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#62089): https://lists.yoctoproject.org/g/yocto/message/62089 Mute This Topic: https://lists.yoctoproject.org/mt/103332846/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Need comments or plan on User- group guidelines which is making us away from commercial products
On Wed, Nov 1, 2023 at 6:43 AM Ravi Kumar wrote: > > Hi team , > Most of the IOT lines have been deployed on Yocto now the new > trend/requirement is security . > On yocto we see that we moved away making every one as root and every > resource on the device tree accessible . > Where it creates new challenges of creating isolation of services > and resources . > Making a service to run in low privilege mode (which is a base > requirement of security ) . > I understand we had always encouraged using extrausers and useradd > for creating custom user groups. > [1] https://docs.yoctoproject.org/ref-manual/classes.html#extrausers > [2] https://docs.yoctoproject.org/ref-manual/classes.html#useradd > > > Following are the problems . > we add a new UID and GID and associate the new code , But open > source service might still need to be part of this group to access > this. > where adding /covering all the use cases is really not possible . > Re-using of the code which is already associated with some user group > has to be reworked to make sure the UID and GID is unique . > > We see that we are moving aways from commercial product lines in terms > of security. How do we address this or the proposal? > > 1. Standardization of user /group : > Just like android echo system uid /gid classification based on > . to be defined . driver related / app related / services > > 2. Default group to be included by Yocto frameworks . > like > Radio -- moden board are by default enable with wifi , BT , GPS > 3. users who are part of special capabilities groups like net_admin > /net_raw, reading of /proc > or writing to /sys entries which could do elevated roles. > > Selinux sort of layer is ontop of DAC (legacy user/groups ) and we > should be having a robust DAC model to meet the current security > requirements. > Please let us know if there are any guidelines / plans on this . > Or can we submit a patch for adding default /user like raido / > net_admin sort of users. > Hello Ravi, Thank you for the message. I'm not aware of a recent discussion on the subjet, and the question is relavant. I'm adding the yocto-security@ mailing list in copy. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61547): https://lists.yoctoproject.org/g/yocto/message/61547 Mute This Topic: https://lists.yoctoproject.org/mt/102313578/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] CVE management and SRTool test update
Dear all, Here's the update on our CVE management research work for YP. Contest: a frequent request is to be able to answer "is YP affected by this particular CVE". We have a part of an answer in the cve-check, but not the triage of issues YP is not affected at all. This research includes two elements: Manual CVE triage tests SRTool investigation Manual CVE triage tests === Marta has done manual triage of two sets of two days: one manual (download from CVE JSON5 database) and one via SRTool. Manual triage: 2h SRTool triage: 1.5h (but manual triage was done earlier) Take-aways: - a huge majority of issues does not affect YP - those that do are most of the time already listed in cve-check results - the effective procedure to check was "git grep" to find if we have a recipe (Layer index could be used too), then checking a "world" run of cve-check. Only rarely manual verifications are needed. - found some CPE mismatches etc (patches will come) - if we want to set up triage, we need to clearly define which layers we take care of. For example, in one of the sets there were numerous Java runtime issues. Also other issues in packages from various layers. To sum up, the triage takes around 1h/day without automation. However, it should be way sgorter if pre-triaged with cve-check result and package list from supported layers. Open questions: who will be willing to participate in the effort? SRTool investigation We have had a call on October 19th (people present in CC). Subjects discussed: 1. Installing SRTool Marta has a running instance, Alex plans to set up one 2. Workflow David explained how the investigation is done at WR. "Vulnerability" describes a problem, can link to multiple CVEs (for example from multiple researchers). From Vulnerabilities they create Investigations (1:1 for each product - in our case YP releases). Defects are handles in the bug tracker. A proposal of David was to integrate Bugzilla and trace CVE entries, import them into investigations. This would mean to use bugs to populate CVE statuses. However, we could not use that approach with YP right now, as CVE entries aren't managed in Bugzilla. There's another subject on CVE patches synchronization work, see https://lists.yoctoproject.org/g/yocto-security/message/964 We have information on what version is affected/not affected from the cve-check. Then David has shown the "Audit" functionality. It can be populated from cve-check. Agreed to do a PoC implementation (David will work on it). When CVEs are filled from cve-check, only a certain number of CVEs will be left with unknown status. Marta hopes they will be easy to handle. 3. Result sharing We discussed how triage results from YP can be used by other vendors. It seems possible to do that via "audit" sources. Next meeting planned on Nov 2nd. Everyone willing to participate is welcome (send me or David a message to be added to the invitation). Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61446): https://lists.yoctoproject.org/g/yocto/message/61446 Mute This Topic: https://lists.yoctoproject.org/mt/102131075/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] SRTool usage for CVE management at YP
Hello all, There' a discussion pending on the usage of SRTool and CVE management for the Yocto project in general. It is related to the need of having a list of CVEs the project is affected by, those fixed and those that we know we are not affected. In the previous episode, we have had a demo of SRTool by David Reyna. This weekend he has updated the code base. The next call is tomorrow (Thursday, 19th October, half an hour after the end of the Bug Triage meeting) to discuss conclusions of first tests and the next steps. If you are interested to join, let us know! Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61384): https://lists.yoctoproject.org/g/yocto/message/61384 Mute This Topic: https://lists.yoctoproject.org/mt/102034248/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Yocto Project security work in progress: call for contributions
Hello all, There's an ongoing work on the YP security and we have had an interesting discussion during the weekly meeting on September 26. Slides used are available from the wiki [1]. If you're interested i security subjects, please comment on the content. Two processes are currently in the works: - the vulnerability reporting process and the security team [2] (complete, ready for review) - the CVE synchronization [3] (work in progress) They are working for your feedback! We are also searching for people who will like to join the group experimenting with CVE work synchronization. Kind regards, Marta [1] https://wiki.yoctoproject.org/wiki/File:Yocto_Project_Security_-_26_09_2023.pdf [2] https://wiki.yoctoproject.org/wiki/Security_private_reporting [3] https://wiki.yoctoproject.org/wiki/Synchronization_CVEs -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61171): https://lists.yoctoproject.org/g/yocto/message/61171 Mute This Topic: https://lists.yoctoproject.org/mt/101663409/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] SPDX generation fails every second time the image is created
Hello David, I haven't encountered this one, but it looks like a race condition. Could you tell us which exact version of the YP are you using? What is your configuration, if you can share (which layers and packages activated, especially). Kind regards, Marta On Thu, Sep 28, 2023 at 4:20 PM David Daniel wrote: > > Hello > > Something changed in master the last days that makes the image creation > fail. When I create the image with bitbake, every second time the image > creation fails with: > >Exception: AttributeError: 'NoneType' object has no attribute 'open' > > Funnily this only happens every 2nd time - afterwards I cannot build > the image anymore. Up to now I "solve" this by deleting the entire > build folder and start over again. > I attached the log of the build that shows the error - I don't > understand where this comes from. > > Any idea what's causing this? > > Have a great day, > BR > David > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61159): https://lists.yoctoproject.org/g/yocto/message/61159 Mute This Topic: https://lists.yoctoproject.org/mt/101638471/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] [yocto] Security processes: YP needs
On Wed, 27 Sept 2023, 12:05 Reyna, David, wrote: > Hi Marta! > > > What about 11am Pacific on tomorrow (28 Sept or Oct 3)? > > Let us aim for October 3 so that I can prepare a full demo.. > > > I think that you have meant 10am to 2PM, otherwise 1am Pacific would > work very well for me too > > I actually did mean 2:00 am Pacific. I do work with our India team, so I > am often up late to sync with them.. > > > As discussed yesterday in the call, there are some other people who seem > interested. > > What time zone are you in? > I believe Ross is in England (UTC) > I know that Randy is in Ottawa. > > If anyone else wants to join, that would be great!. They should ping us > and I can send the Zoom link. I do not want to send that link blindly to > the full mail list. > I'm in CEST (Central European zone). If we aim for the 3rd then let's stay for late afternoon for me. I let Ross, Randy and everyone else interested to express their preferences. > > I'm going to add the missing file for the test next week, the tool needs > a script to download 2023 data. > > That file is part of my code update, so you can get that for free. > Thanks! David > > -Original Message- > From: Marta Rybczynska > Sent: Wednesday, September 27, 2023 12:18 AM > To: Reyna, David > Cc: yocto-secur...@lists.yoctoproject.org; OE-core < > openembedded-c...@lists.openembedded.org>; > openembedded-architect...@lists.openembedded.org; > yocto@lists.yoctoproject.org; MacLeod, Randy ; > Richard Purdie ; Steve Sakoman < > st...@sakoman.com>; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: Re: [Openembedded-architecture] [yocto] Security processes: YP > needs > > Hi David, > Thank you very much for the description and the offer to get a demo. > As discussed yesterday in the call, there are some other people who > seem interested. > > > PROPOSAL 1: If the full triage is too much to bite off to start with, > perhaps using it to track and coordinate work will bring immediate benefit. > > This is the reason I want to test how much time it takes. > > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. > I am available pretty much anytime between 10:00 am Pacific to 2:00 am > Pacific. > > That would be nice. What about 11am Pacific on tomorrow (28 Sept or > Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific > would work very well for me too :P > > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my > current implementation level from Wind River (with the Wind River specific > modules left out of course :-) > > That would be great. I'm going to add the missing file for the test > next week, the tool needs a script to download 2023 data. > > Kind regards, > Marta > > On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via > lists.openembedded.org > wrote: > > > > Hi Marta, > > > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > > > There are many ways to use the SRTool. > > (a) The original design was to perform 100% triage of incoming CVEs. > This was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > > (b) The main limitation with the SRTool for Yocto Project was the > lack of integration with Bugzilla (Ross ran out of time) > > * This is the crucial other half of the workflow > > * There is the automatic creation of appropriate defect records for > investigation > > * There is also the automatic tracking of the overall CVE status, > both CVEs in progress and the CVEs completed > > * Wind River has an extension for full integration with Jira, and > that saves weeks of work for the CVE management > > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate > of domains > > (d) The SRTool has a user model > > * Together with Bugzilla, it is easy to track single people and > even multiple people working on CVEs > > (e) The SRTool also has the built-on ability to look up the CVE status > from other distributions (Red Hat, Debian, ...) so that one can get a peek > of existing triages and resolutions > > (f) The SRTool is build like Toaster on top of Django, so development > and debugging skills for Toaster immediate apply > > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support
Re: [Openembedded-architecture] [yocto] Security processes: YP needs
Hi David, Thank you very much for the description and the offer to get a demo. As discussed yesterday in the call, there are some other people who seem interested. > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. This is the reason I want to test how much time it takes. > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. That would be nice. What about 11am Pacific on tomorrow (28 Sept or Oct 3)? I think that you have meant 10am to 2PM, otherwise 1am Pacific would work very well for me too :P > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) That would be great. I'm going to add the missing file for the test next week, the tool needs a script to download 2023 data. Kind regards, Marta On Mon, Sep 25, 2023 at 11:02 AM Reyna, David via lists.openembedded.org wrote: > > Hi Marta, > > * SRTool: We might decide to use it again. It allows one to do much but > requires constant commitment. > > There are many ways to use the SRTool. > (a) The original design was to perform 100% triage of incoming CVEs. This > was a business requirement of Wind River, and we have used the SRTool > successfully for 4-5 year now. > (b) The main limitation with the SRTool for Yocto Project was the lack of > integration with Bugzilla (Ross ran out of time) > * This is the crucial other half of the workflow > * There is the automatic creation of appropriate defect records for > investigation > * There is also the automatic tracking of the overall CVE status, both > CVEs in progress and the CVEs completed > * Wind River has an extension for full integration with Jira, and that > saves weeks of work for the CVE management > (c) The guiding rule was that CVE management was in the SRTool, but > specific defect work was also done in Jira/Bugzilla, for a clean separate of > domains > (d) The SRTool has a user model > * Together with Bugzilla, it is easy to track single people and even > multiple people working on CVEs > (e) The SRTool also has the built-on ability to look up the CVE status from > other distributions (Red Hat, Debian, ...) so that one can get a peek of > existing triages and resolutions > (f) The SRTool is build like Toaster on top of Django, so development and > debugging skills for Toaster immediate apply > (g) Also with the Django base, it is very simple to add any number of > modular extensions to support for example CVE Scanner integration > (h) The SRTool also has report generation (in text, CSV, and Excel) in > addition to email notification support. > (i) There is also a "private" model for CVEs under embargo, with strict > access control lists. > > PROPOSAL 1: If the full triage is too much to bite off to start with, perhaps > using it to track and coordinate work will bring immediate benefit. > > PROPOSAL 2: I am happy to give you a live demo of Wind River's fully > operational SRTool, so you can see all of the bells and whistles in action. I > am available pretty much anytime between 10:00 am Pacific to 2:00 am Pacific. > > PROPOSAL 3: I will start refreshing the YP SRTool repository with my current > implementation level from Wind River (with the Wind River specific modules > left out of course :-) > > David > > BTW, I also support an extension to the SRTool that manages CVE scanning of > build images, with hooks to a number existing CVE scanners (e.g. Trivy) in > addition to other vulnerability metrics. This is probably out of scope to YP > at this time, but it is perhaps something to grow in to. > > -Original Message- > From: yocto@lists.yoctoproject.org On Behalf > Of Marta Rybczynska via lists.yoctoproject.org > Sent: Wednesday, September 13, 2023 4:52 AM > To: yocto-secur...@lists.yoctoproject.org; OE-core > ; > openembedded-architect...@lists.openembedded.org; yocto@lists.yoctoproject.org > Cc: Richard Purdie ; Steve Sakoman > ; Khem Raj ; > mark.ha...@kernel.crashing.org; Ross Burton ; Joshua > Watt > Subject: [yocto] Security processes: YP needs > > Hello, > I've been working recently on collecting what works and what doesn't > in YP security processes. The goal is to go forward and define an > actionable strategy! > > Today, I'd like to share with you the summary of what I have heard as > needs from several people (those in Cc:). > > I want the
[yocto] YP/OE event around FOSDEM 2024?
Hello, Is there a plan to have an OE/YP event around FOSDEM? As a reminder, FOSDEM 2024 is on the 3rd and 4th of February 2024 in Brussels. I'm asking, because related events are already being scheduled around... Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61076): https://lists.yoctoproject.org/g/yocto/message/61076 Mute This Topic: https://lists.yoctoproject.org/mt/101516767/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 6:00 PM Alex Stewart wrote: > > Thanks for driving this Marta. Internally and externally, it feels like > we're just on the cusp of everyone *suddenly caring* about our security > response strategy. So it's good to see that we're making moves in that > direction. > Thank you Alex! > > More responses inline. > > On 9/13/23 07:52, Marta Rybczynska via lists.openembedded.org wrote: > > * CVEs: Visibility if YP is vulnerable or not > > > > People want to be able to check/look up a specific CVE; it might be a > > CVE unrelated to YP > > (eg. package not included, Windows issue). The cve-checker result is a > > part of the solution, but people also want to know which CVEs do not > > apply. > > I'm not sure I understand this usecase. Is there a reason those people > can't/won't just lookup the CVE on the NIST site? > Mark's answer is clarifying that. I'll add that this is a requirement I have heard from multiple sources. People might look up CVE/NIST, but that takes time if you are required to look up all CVEs. If we have common data, we avoid duplicate work. > > * CVEs: synchronization of the work on fixes > > > > Currently, there is no synchronization; multiple parties might be > > working on the same fix while nobody is working on another. There > > might be duplication of work. > > Ross has https://wiki.yoctoproject.org/wiki/CVE_Status > > Has there been any discussion of adopting the OpenVEX document standard > that the Chainguard guys are putting together? [1] It seems like the VEX > use-cases align well with our needs around tracking and coordinating CVE > response between YP member and individual developers. > We might decide to use it. However, openVEX a way to output the data we have/will have (the conclusion), not a way to sync up the work. > > > * Triaging of security issues > > > > Related to CVE fixes and includes issues reported directly to the YP. > > Some issues are more likely to be serious for embedded products > > (attack by network), so not all has the same priority. > > I'll note here that some of us are sinners and do actually support > network-attached (and internet-attached) embedded devices. :) > > But the greater point of OS vendors being able to triage and assign > vendor-specific severities to incoming issues is absolutely important to > my use-cases. > This is an important point. YP is generic and YP assesment of severity might be different than the one from a vendor. It means that our process should be flexible enough that a vendor can take the data and assign their own severity. > > > > * Visibility of the security work of the YP > > > > There is much work on security in the YP, but it lacks visibility. > > Is there a common nexus for this work? eg. do most of the folks who are > doing security work tend to congregate on the security sublist? I'd like to know :) This thread is a big cross-post (and sorry for that, but I need to reach the whole audience), for further discussions I'd like to invite all to a dedicate list. > > > * Additional tooling > > > > We could add additional tooling: a template on how to add cve-check to > > the CI (possibly > > a different one than the autobuilder), analyze the result, and extend > > our tooling to their layers... > > It is also related to the "Architecture" topic below. > > Can you expand on what you mean here? Is this usecase about extending > the existing tooling into the generic CI processes that YP members are > using, or about expanding the tooling in the YP's indigenous CI? This is a requirement assembling multiple ones. Many people mentioned that additional tooling would be needed and/or helpful. A CI template is an example here. I'm interested in your list of tooling that would be important or useful to have. Preferably related to processes that are currently done in-house and that we can make more generic and share the work. > > > * Presence on pre-notification lists and receiving information before > > the vulnerability gets public > > > > YP currently depends on public data. Principal distributions receive > > the information before > > a vulnerability becomes public. It requires (in short) private > > reporting, a security team, and a track > > of excellent security record. > > > > * Becoming a CNA (be able to assign CVEs) > > > > Needed if we want to assign CVEs to the software of the YP, like > > autobuilder, Toaster etc. > > I'm also interested in this, as the maintainer of our opkg fork. So far, > I haven't had to respond to a CVE against the project, but that won't > last forever. CVEs against a fork, t
Re: [yocto] [Openembedded-architecture] Security processes: YP needs
On Wed, Sep 13, 2023 at 2:33 PM Mikko Rapeli wrote: > > Hi, > > On Wed, Sep 13, 2023 at 01:52:19PM +0200, Marta Rybczynska wrote: > > Hello, > > I've been working recently on collecting what works and what doesn't > > in YP security processes. The goal is to go forward and define an > > actionable strategy! > > > > Today, I'd like to share with you the summary of what I have heard as > > needs from several people (those in Cc:). > > > > I want the community to comment and tell us what you find important > > and what you'd like to see added or changed from this list. > > Since most users take poky reference distro and combine it with a number > of open source and closed source BSP and other meta layers and build > systems to produce SW for products, they also need documentation and tooling > so that they can replicate the Yocto Project security processes and use the > available tools. Do you also mean that we should make sure Poky follows security best practices? Noted the point on documenting the way process works/will work so other teams can extend it to their layer. > > I think most of the documentation around the tools and processes is in place > already. > Having maintained and shipped from a non-maintained poky branch, I can just > say > thank you to all who participated in the upstream work to get security > vulnerability > detection and fixing possible! > Out of curiosity, what have you backported? cve-check? LTS work? > That being said, extending the CVE scanning and status tracking work to > include more > open source layers would be nice both for the maintainers and for the users > of those > layers. Using some random old branch of meta-foo may not be so safe. Maybe add > this data to layer-index? > We have Yocto Project Compatible already. Do we need something else? Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61014): https://lists.yoctoproject.org/g/yocto/message/61014 Mute This Topic: https://lists.yoctoproject.org/mt/101335538/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Security processes: YP needs
Hello, I've been working recently on collecting what works and what doesn't in YP security processes. The goal is to go forward and define an actionable strategy! Today, I'd like to share with you the summary of what I have heard as needs from several people (those in Cc:). I want the community to comment and tell us what you find important and what you'd like to see added or changed from this list. * CVEs: Visibility if YP is vulnerable or not People want to be able to check/look up a specific CVE; it might be a CVE unrelated to YP (eg. package not included, Windows issue). The cve-checker result is a part of the solution, but people also want to know which CVEs do not apply. * CVEs: synchronization of the work on fixes Currently, there is no synchronization; multiple parties might be working on the same fix while nobody is working on another. There might be duplication of work. Ross has https://wiki.yoctoproject.org/wiki/CVE_Status * Triaging of security issues Related to CVE fixes and includes issues reported directly to the YP. Some issues are more likely to be serious for embedded products (attack by network), so not all has the same priority. * Private security communication A way to send a notification of a non-public security issue. For researchers, other projects etc. The security alias exists, but only some people know about its existence. * Visibility of the security work of the YP There is much work on security in the YP, but it lacks visibility. * Documentation Related to visibility. We need easy-to-find documentation of subjects like submitting a CVE fix, reporting a private issue, and how our processes work... This documentation should address people who are not regular contributors. * Additional tooling We could add additional tooling: a template on how to add cve-check to the CI (possibly a different one than the autobuilder), analyze the result, and extend our tooling to their layers... It is also related to the "Architecture" topic below. * Architecture work Security if more than CVE fixes. We also have what is happening in meta-security: hardening, compiler option, secure package configuration, use of code coverage tools, and so on * SRTool We might decide to use it again. It allows one to do much but requires constant commitment. * Presence on pre-notification lists and receiving information before the vulnerability gets public YP currently depends on public data. Principal distributions receive the information before a vulnerability becomes public. It requires (in short) private reporting, a security team, and a track of excellent security record. * Becoming a CNA (be able to assign CVEs) Needed if we want to assign CVEs to the software of the YP, like autobuilder, Toaster etc. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#60983): https://lists.yoctoproject.org/g/yocto/message/60983 Mute This Topic: https://lists.yoctoproject.org/mt/101334936/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [OE-core] Yocto Project Status 02 August 2022 (WW31)
On Tue, Aug 2, 2022 at 4:49 PM Neal Caidin wrote: > > Current Dev Position: YP 4.1 M3 > > Next Deadline: 22nd August 2022 YP 4.1 M3 Build > > > Next Team Meetings: > > Bug Triage meeting Thursday August 4th 7:30 am PDT > (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09) > > Weekly Project Engineering Sync Tuesday August 2nd at 8 am PDT > (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09) > > Twitch - See https://www.twitch.tv/theyoctojester > > > Key Status/Updates: > > YP 4.1 M2 was released > > YP 3.1.18 passed QA and is due to be released > > The debug file mapping issues have moved slightly further forward thanks to > some help from Ross but are stalling due to insufficient developer time > available to resolve the issues. > > Some rust toolchain improvements did merge, including an automated rust > toolchain test. The bulk of the rework is stalled on a handful of remaining > issues, particularly a couple of reproducibility problems but also a mips n32 > toolchain issue. > > We have one open CVE on master against qemu, help to backport that fix would > be very welcome to keep the numbers down. CVEs in kirkstone (LTS) > significantly reduced. Do you mean CVE-2022-35414? Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57740): https://lists.yoctoproject.org/g/yocto/message/57740 Mute This Topic: https://lists.yoctoproject.org/mt/92774088/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] cve check report package version mismatch #yocto
On Tue, Jul 5, 2022 at 2:31 PM wrote: > > I used the cve check class by including it in the local.conf and then ran the > bitbake build process for my image. I got a log of all the detected CVEs in > the packages used in the build. However, on closer inspection, I noticed that > the packages used in the build are already higher version than when the CVE > was patched. Here is an example: > > LAYER: meta > PACKAGE NAME: libksba > PACKAGE VERSION: 1.6.0 > CVE: CVE-2016-4355 > CVE STATUS: Patched Hello Gaurav, The CVE STATUS "Patched" means that there was an issue in the past, but it is either fixed or otherwise mitigated. Open issues are marked as "Unpatched". If you'd like to see only Unpatched issues in the report, please use CVE_CHECK_REPORT_PATCHED = "0" in your local.conf or other place you have your OE configuration from. Kind regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57460): https://lists.yoctoproject.org/g/yocto/message/57460 Mute This Topic: https://lists.yoctoproject.org/mt/92183457/21656 Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-zephyr] meets create-spdx
Hello all,
We're trying to use create-spdx.bbclass with meta-zephyr. However,
this is failing with errors like the one at the bottom of the message.
While digging deeper, it is hard to reproduce reliably (but happens at
different recipes and frequently enough to have it at every build).
The workaround that works is to add:
do_create_spdx[nostamp] = "1"
which isn't great.
Has anyone tried create-spdx.bbclass with meta-zephyr? Any insight?
Kind regards,
Marta
And an example error message:
ERROR: python3-native-3.10.4-r0 do_create_spdx: Error executing a
python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function:
0001:
*** 0002:do_create_spdx(d)
0003:
File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/classes/create-spdx.bbclass',
lineno: 516, function: do_create_spdx
0512:
0513: if archive is not None:
0514: recipe.packageFileName = str(recipe_archive.name)
0515:
*** 0516: dep_recipes = collect_dep_recipes(d, doc, recipe)
0517:
0518: doc_sha1 = oe.sbom.write_doc(d, doc, "recipes")
0519: dep_recipes.append(oe.sbom.DepRecipe(doc, doc_sha1, recipe))
0520:
File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/classes/create-spdx.bbclass',
lineno: 345, function: collect_dep_recipes
0341: ))
0342: for dep_pn in deps:
0343: dep_recipe_path = deploy_dir_spdx / "recipes" /
("recipe-%s.spdx.json" % dep_pn)
0344:
*** 0345: spdx_dep_doc, spdx_dep_sha1 = oe.sbom.read_doc(dep_recipe_path)
0346:
0347: for pkg in spdx_dep_doc.packages:
0348: if pkg.name == dep_pn:
0349: spdx_dep_recipe = pkg
File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/lib/oe/sbom.py', lineno:
67, function: read_doc
0063: else:
0064: with fn.open("rb") as f:
0065: yield f
0066:
*** 0067: with get_file() as f:
0068: sha1 = hashlib.sha1()
0069: while True:
0070: chunk = f.read(4096)
0071: if not chunk:
File: '/usr/lib/python3.8/contextlib.py', lineno: 113, function: __enter__
0109: # do not keep args and kwds alive unnecessarily
0110: # they are only needed for recreation, which is not possible anymore
0111: del self.args, self.kwds, self.func
0112: try:
*** 0113: return next(self.gen)
0114: except StopIteration:
0115: raise RuntimeError("generator didn't yield") from None
0116:
0117: def __exit__(self, type, value, traceback):
File: '/tmp/workspace.yd5o77EYlf/oe-core/meta/lib/oe/sbom.py', lineno:
64, function: get_file
0060: def get_file():
0061: if isinstance(fn, io.IOBase):
0062: yield fn
0063: else:
*** 0064: with fn.open("rb") as f:
0065: yield f
0066:
0067: with get_file() as f:
0068: sha1 = hashlib.sha1()
File: '/usr/lib/python3.8/pathlib.py', lineno: 1222, function: open
1218: the built-in open() function does.
1219: """
1220: if self._closed:
1221: self._raise_closed()
*** 1222: return io.open(self, mode, buffering, encoding, errors, newline,
1223: opener=self._opener)
1224:
1225: def read_bytes(self):
1226: """
File: '/usr/lib/python3.8/pathlib.py', lineno: 1078, function: _opener
1074: raise ValueError("I/O operation on closed path")
1075:
1076: def _opener(self, name, flags, mode=0o666):
1077: # A stub for the opener argument to built-in open()
*** 1078: return self._accessor.open(self, flags, mode)
1079:
1080: def _raw_open(self, flags, mode=0o777):
1081: """
1082: Open the file pointed by this path and return a file descriptor,
Exception: FileNotFoundError: [Errno 2] No such file or directory:
'/tmp/workspace.yd5o77EYlf/build/tmp-newlib/deploy/spdx/qemu-cortex-m3/recipes/recipe-gnu-config-native.spdx.json'
ERROR: Logfile of failure stored in:
/tmp/workspace.yd5o77EYlf/build/tmp-newlib/work/x86_64-linux/python3-native/3.10.4-r0/temp/log.do_create_spdx.12842
NOTE: recipe python3-native-3.10.4-r0: task do_create_spdx: Failed
ERROR: Task
(virtual:native:/tmp/workspace.yd5o77EYlf/oe-core/meta/recipes-devtools/python/python3_3.10.4.bb:do_create_spdx)
failed with exit code '1'
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57434): https://lists.yoctoproject.org/g/yocto/message/57434
Mute This Topic: https://lists.yoctoproject.org/mt/92103690/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [oe] Inclusive Language Proposal for YP/OE
On Mon, Jan 24, 2022 at 5:18 PM Jon Mason wrote: > CVE_CHECK_PN_WHITELIST -> CVE_CHECK_SKIPRECIPE > CVE_CHECK_WHITELIST -> CVE_CHECK_IGNORECVE > When running master-next I have found one missing rename, cve-check has "CVE STATUS" result which is still Patched, Unpatched, Whitelisted. I propose to rename Whitelisted to Ignored to be in-line with the variable rename. Is there anyone using the states in scripting or other tools today? Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#56220): https://lists.yoctoproject.org/g/yocto/message/56220 Mute This Topic: https://lists.yoctoproject.org/mt/89289633/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-hardening][PATCH] meta-hardening/binutils: harden installation permissions
(correcting the wrong list address) On Fri, Aug 27, 2021 at 6:07 AM akuster808 wrote: > Marta, > > On 8/24/21 11:05 PM, Marta Rybczynska wrote: > > Compilers and related utils are better restricted on production > platforms. > > Change permissions of all installed binutils tools to remove access from > > users outside of the root group. > > > > This also demonstrates how to restrict file permissions in a hardened > > distribution. > > Have you looked into FILESYSTEM_PERMS_TABLES? An example of the format > can be found @ /meta/files/fs-perms.txt > > For more info see > https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html > > Maybe having something like fs-perms.txt in meta-hardening may achieve > the same? > > It looks like a possibility, I will give it a try. I have a question about the future, however. Currently meta-hardening is defining its own distribution. When hardening will be in DISTRO_FEATURES (you were working on it some time ago https://patchwork.openembedded.org/patch/174773/), it would be less obvious to use, wouldn't it? A bonus question, do you still plan to make it in DISTRO_FEATURES? Regards, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54604): https://lists.yoctoproject.org/g/yocto/message/54604 Mute This Topic: https://lists.yoctoproject.org/mt/85129693/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-tpm][PATCH v2] README: fix mailing lists and a typo
A number of typo fixes: - tmp->tpm in the DISTRO_FEATURES - update the mailing list address as it was out of date - update the distro name in the subject Signed-off-by: Marta Rybczynska --- meta-tpm/README | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/meta-tpm/README b/meta-tpm/README index 4441dd2..2b32a9f 100644 --- a/meta-tpm/README +++ b/meta-tpm/README @@ -5,7 +5,7 @@ The bbappend files for some recipes (e.g. linux-yocto) in this layer need to have 'tpm' in DISTRO_FEATURES to have effect. To enable them, add in configuration file the following line. - DISTRO_FEATURES:append = " tmp" + DISTRO_FEATURES:append = " tpm" If meta-tpm is included, but tpm is not enabled as a distro feature a warning is printed at parse time: @@ -57,15 +57,15 @@ other layers needed. e.g.: Maintenance --- -Send pull requests, patches, comments or questions to yo...@yoctoproject.org +Send pull requests, patches, comments or questions to yocto@lists.yoctoproject.org When sending single patches, please using something like: -'git send-email -1 --to yo...@yoctoproject.org --subject-prefix=meta-security][PATCH' +'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-tpm][PATCH' These values can be set as defaults for this repository: -$ git config sendemail.to yo...@yoctoproject.org -$ git config format.subjectPrefix meta-security][PATCH +$ git config sendemail.to yocto@lists.yoctoproject.org +$ git config format.subjectPrefix meta-tpm][PATCH Now you can just do 'git send-email origin/master' to send all local patches. -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54558): https://lists.yoctoproject.org/g/yocto/message/54558 Mute This Topic: https://lists.yoctoproject.org/mt/85135317/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-tpm][PATCH] README: fix mailing lists and a typo
A number of typo fixes: - tmp->tpm in the DISTRO_FEATURES - update the mailing list address as it was out of date - update the distro name in the subject Signed-off-by: Marta Rybczynska --- meta-tpm/README | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-tpm/README b/meta-tpm/README index 4441dd2..5722a92 100644 --- a/meta-tpm/README +++ b/meta-tpm/README @@ -5,7 +5,7 @@ The bbappend files for some recipes (e.g. linux-yocto) in this layer need to have 'tpm' in DISTRO_FEATURES to have effect. To enable them, add in configuration file the following line. - DISTRO_FEATURES:append = " tmp" + DISTRO_FEATURES:append = " tpm" If meta-tpm is included, but tpm is not enabled as a distro feature a warning is printed at parse time: @@ -57,14 +57,14 @@ other layers needed. e.g.: Maintenance --- -Send pull requests, patches, comments or questions to yo...@yoctoproject.org +Send pull requests, patches, comments or questions to yocto@lists.yoctoproject.org When sending single patches, please using something like: -'git send-email -1 --to yo...@yoctoproject.org --subject-prefix=meta-security][PATCH' +'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-security][PATCH' These values can be set as defaults for this repository: -$ git config sendemail.to yo...@yoctoproject.org +$ git config sendemail.to yocto@lists.yoctoproject.org $ git config format.subjectPrefix meta-security][PATCH Now you can just do 'git send-email origin/master' to send all local patches. -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54557): https://lists.yoctoproject.org/g/yocto/message/54557 Mute This Topic: https://lists.yoctoproject.org/mt/85135124/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-hardening][PATCH] README: fix mailing lists
The address included in the meta-hardening documentation does not work and was changed in other places in 2019. Signed-off-by: Marta Rybczynska --- meta-hardening/README | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta-hardening/README b/meta-hardening/README index 37a0b7e..191253c 100644 --- a/meta-hardening/README +++ b/meta-hardening/README @@ -64,14 +64,14 @@ layers: meta-oe Maintenance --- -Send pull requests, patches, comments or questions to yo...@yoctoproject.org +Send pull requests, patches, comments or questions to yocto@lists.yoctoproject.org When sending single patches, please using something like: -'git send-email -1 --to yo...@yoctoproject.org --subject-prefix=meta-hardening][PATCH' +'git send-email -1 --to yocto@lists.yoctoproject.org --subject-prefix=meta-hardening][PATCH' These values can be set as defaults for this repository: -$ git config sendemail.to yo...@yoctoproject.org +$ git config sendemail.to yocto@lists.yoctoproject.org $ git config format.subjectPrefix meta-hardening][PATCH Now you can just do 'git send-email origin/master' to send all local patches. -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#54554): https://lists.yoctoproject.org/g/yocto/message/54554 Mute This Topic: https://lists.yoctoproject.org/mt/85129829/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-hardening][PATCH] meta-hardening/binutils: harden installation permissions
Compilers and related utils are better restricted on production platforms.
Change permissions of all installed binutils tools to remove access from
users outside of the root group.
This also demonstrates how to restrict file permissions in a hardened
distribution.
Signed-off-by: Marta Rybczynska
---
meta-hardening/recipes-devtools/binutils/binutils_%.bbappend | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
diff --git a/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
b/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
new file mode 100644
index 000..3eb3ad0
--- /dev/null
+++ b/meta-hardening/recipes-devtools/binutils/binutils_%.bbappend
@@ -0,0 +1,3 @@
+do_install_append_class-target () {
+chmod o-rx ${D}${prefix}/${TARGET_SYS}/bin/*
+}
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54553): https://lists.yoctoproject.org/g/yocto/message/54553
Mute This Topic: https://lists.yoctoproject.org/mt/85129693/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
