[Openembedded-architecture] 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 (#1786): https://lists.openembedded.org/g/openembedded-architecture/message/1786 Mute This Topic: https://lists.openembedded.org/mt/101663407/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Fri, 29 Sept 2023 at 14:27, Richard Purdie wrote: > I'd prefer to see some dedicated bitbake API used even if we need to > create/add it. tinfoil and some of the bblock/unlock work shows we can > get stamp data, the question would be how to get it without > "disturbing" the existing build. > > By using dedicated API, we'd be able to control the console output. I just noticed that compare_sigfiles() has a 'collapsed' argument, which, when set to True, omits most or all of the task hash printing, and with that its output should approximate what bitbake-whatchanged is aiming to do. This is currently used only by buildhistory, but it could be used by -S printdiff too, e.g. by having verbose and concise modes. I'll run some experiments, and let's see what the overall output looks like in real scenarios (e.g. 4.3_M3 vs current master). Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1785): https://lists.openembedded.org/g/openembedded-architecture/message/1785 Mute This Topic: https://lists.openembedded.org/mt/101356419/21656 Group Owner: openembedded-architecture+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Fri, 2023-09-29 at 14:06 +0200, Alexander Kanavin wrote:
> On Thu, 28 Sept 2023 at 18:49, Richard Purdie
> wrote:
>
> > I'm curious to see what you find with analysis of bitbake-whatchanged.
>
> I've taken a look a the script. It obtains the current location of
> STAMPS_DIR, then runs this:
>
> # Generate the new stamps dir
> print("Generating the new stamps ... (need several minutes)")
> cmdline = "STAMPS_DIR=%s bitbake -S none %s" % (new_stampsdir,
> args.recipe)
>
> Then it walks both trees, matching up file names with a regex:
>
> # Match the stamp's filename
> # group(1): PE_PV (may no PE)
> # group(2): PR
> # group(3): TASK
> # group(4): HASH
> stamp_re =
> re.compile("(?P.*)-(?Pr\d+)\.(?Pdo_\w+)\.(?P[^\.]*)")
>
> Then there's some code that finds out what changed in the above
> between the two sets.
>
> I don't see a way to make it work: messing about with STAMPS_DIR like
> that isn't supported, and will either do nothing, or remove the
> original stamps. Also stamp filenames aren't really a 'public API',
> are they?
>
> Should the script simply be removed, or is there some better way to
> re-implement answering the 'what has changed' question in a way that
> doesn't flood the console with task hashes? I'd be glad to get
> suggestions for this.
I'd prefer to see some dedicated bitbake API used even if we need to
create/add it. tinfoil and some of the bblock/unlock work shows we can
get stamp data, the question would be how to get it without
"disturbing" the existing build.
By using dedicated API, we'd be able to control the console output.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1784):
https://lists.openembedded.org/g/openembedded-architecture/message/1784
Mute This Topic: https://lists.openembedded.org/mt/101356419/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [Openembedded-architecture] Core workflow: sstate for all, bblock/bbunlock, tools for why is sstate not being reused?
On Thu, 28 Sept 2023 at 18:49, Richard Purdie
wrote:
> I'm curious to see what you find with analysis of bitbake-whatchanged.
I've taken a look a the script. It obtains the current location of
STAMPS_DIR, then runs this:
# Generate the new stamps dir
print("Generating the new stamps ... (need several minutes)")
cmdline = "STAMPS_DIR=%s bitbake -S none %s" % (new_stampsdir,
args.recipe)
Then it walks both trees, matching up file names with a regex:
# Match the stamp's filename
# group(1): PE_PV (may no PE)
# group(2): PR
# group(3): TASK
# group(4): HASH
stamp_re =
re.compile("(?P.*)-(?Pr\d+)\.(?Pdo_\w+)\.(?P[^\.]*)")
Then there's some code that finds out what changed in the above
between the two sets.
I don't see a way to make it work: messing about with STAMPS_DIR like
that isn't supported, and will either do nothing, or remove the
original stamps. Also stamp filenames aren't really a 'public API',
are they?
Should the script simply be removed, or is there some better way to
re-implement answering the 'what has changed' question in a way that
doesn't flood the console with task hashes? I'd be glad to get
suggestions for this.
Alex
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#1783):
https://lists.openembedded.org/g/openembedded-architecture/message/1783
Mute This Topic: https://lists.openembedded.org/mt/101356419/21656
Group Owner: openembedded-architecture+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
