Ah nice, that is definitely something we would be interested in!
Alberto, would you be so kind to share some details?
On Mon, 2024-01-15 at 15:12 +0100, Alexander Kanavin wrote:
> On Mon, 15 Jan 2024 at 15:05, Alexander Kanavin via
> lists.openembedded.org
>
> wrote:
> >
> > On Mon, 15 Jan 2024
Thanks, good to know! Well, that buries that idea then I guess... we
will have to somehow deal with the release tarballs then I guess.
On Mon, 2024-01-15 at 15:05 +0100, Alexander Kanavin wrote:
> On Mon, 15 Jan 2024 at 15:03, Jasper Orschulko
> wrote:
> >
> > > Sadly it wouldn't.
> Sadly it wouldn't. Auto-generated github archives are known to be
> non-deterministic, and we even have a qa check to ensure no recipe is
> using them. I didn't raise this point because my objections are on
> the
> principle of using release tarballs, not this technicality.
Ah ok, that is
Hi Etienne,
GitHub also provides tarballs for the unmodified source code,
e.g.:https://github.com/libexpat/libexpat/archive/refs/tags/R_2_5_0.tar.gz
This corresponds to the "Source Code" asset that Github automatically
adds to releases, see:
Hi Alex,
> Okay, I've read the README file in that repo, and if i understood it
> right, the process is:
> - run fossology
> - have a human inspect the output, and correct it on a file by file
> basis (tremendous waste of time and limited developer resources even
> when done the 'open source way'
Hi all,
The TL;DR:
If no one objects, I would like to put into motion that we gradually
move all oe-core recipes SRC_URIs from Github releases to git source
code (archives) for better source code traceability.
Reasoning follows:
---
Currently, there are (at least¹) 35 recipes in poky that
recipes.
This would allow for a quick adoption and flatten out the path for
making these variables required by default, in turn improving reporting
and security for openembedded products.
Cheers, Jasper
On Fri, 2023-08-25 at 09:57 -1000, Steve Sakoman wrote:
> On Fri, Aug 25, 2023 at 9:18 
uot;matches" (1 CVE on Kernel vs. 300+), but after closer
inspection it turned out that was only due to an optional fuzzy
matching feature in dependencytrack and not because the results
actually improved. Sorry for the trouble.
Cheers, Jasper
On Fri, 2023-08-25 at 09:57 -1000, Steve Sakoman wrote:
>
Hi Richard,
hi all,
I want to address a flaw in the current CPE generation functionality in
openembedded, which renders the CPEs unusable in regards to the minimal
requirements of the NIST CPE Name Matching Specification standard
(https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir7696.pdf).
This
From: Jasper Orschulko
Use "*" (wildcard) instead of "a" (application)in cpe_id generation,
as the product is not necessarily of type application, e.g.
linux_kernel, which is of type "o" (operating system).
(From OE-Core rev: cae9528b002c06143bf048b991b9d7e93968cb6b)
Signed-off-by: Jasper
From: Jasper Orschulko
Use "*" (wildcard) instead of "a" (application)in cpe_id generation,
as the product is not necessarily of type application, e.g.
linux_kernel, which is of type "o" (operating system).
(From OE-Core rev: cae9528b002c06143bf048b991b9d7e93968cb6b)
Signed-off-by: Jasper
From: Jasper Orschulko
Use "*" (wildcard) instead of "a" (application)in cpe_id generation,
as the product is not necessarily of type application, e.g.
linux_kernel, which is of type "o" (operating system).
(From OE-Core rev: cae9528b002c06143bf048b991b9d7e93968cb6b)
Signed-off-by: Jasper
"Jasper Orschulko via lists.openembedded.org"
wrote:
As you can see your sender address has been mangled, and as a result
the patch is rejected by the the openembedded git server. This is not
your fault, but we need you to modify your git con
Use "*" (wildcard) instead of "a" (application)in cpe_id generation,
as the product is not necessarily of type application, e.g.
linux_kernel, which is of type "o" (operating system).
Signed-off-by: Jasper Orschulko
---
meta/lib/oe/cve_check.py | 2 +-
1 file changed, 1 insertion(+), 1
Signed-off-by: Jasper Orschulko
---
meta/recipes-devtools/repo/{repo_2.22.bb => repo_2.23.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/repo/{repo_2.22.bb => repo_2.23.bb} (95%)
diff --git a/meta/recipes-devtools/repo/repo_2.22.bb
From: Jasper Orschulko
Using a task instead of a version specific patch for setting the repo
revision within the source code. This drastically decreases the
maintenance burden and easier usage of the OE update helper.
Signed-off-by: Jasper Orschulko
---
.../0001-Set-REPO_REV-to-v2.17.3.patch
From: Jasper Orschulko
Signed-off-by: Jasper Orschulko
---
meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/repo/{repo_2.17.3.bb => repo_2.18.bb} (95%)
diff --git
From: Jasper Orschulko
Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/conf/distro/include/maintainers.inc | 1 +
.../0001-Set-REPO_REV-to-v2.17.3.patch| 35 +++
.../repo/repo/0001-python3-shebang.patch
From: Jasper Orschulko
Add repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..b709777f24 100644
---
From: Jasper Orschulko
Add repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..b709777f24 100644
---
From: Jasper Orschulko
Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/conf/distro/include/maintainers.inc | 1 +
.../0001-Set-REPO_REV-to-v2.17.3.patch| 35 +++
.../repo/repo/0001-python3-shebang.patch
From: Martin Koppehel
- Implement AUTOINC and submodule support for REPO provider
- Implement full srcrev support
- Add comments and fixup empty DL_DIR initialization
- Distinguish between artificial and plain rev
- Comments/documentation
The previous implementation of the repo fetcher could
From: Martin Koppehel
- Implement AUTOINC and submodule support for REPO provider
- Implement full srcrev support
- Add comments and fixup empty DL_DIR initialization
- Distinguish between artificial and plain rev
- Comments/documentation
The previous implementation of the repo fetcher could
From: Jasper Orschulko
Add git-native and repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..3298bd1952
From: Jasper Orschulko
Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/conf/distro/include/maintainers.inc | 1 +
.../0001-Set-REPO_REV-to-v2.17.3.patch| 35 +++
.../repo/repo/0001-python3-shebang.patch
From: Jasper Orschulko
Add git-native and repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..3298bd1952
From: Jasper Orschulko
Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/conf/distro/include/maintainers.inc | 1 +
.../0001-Set-REPO_REV-to-v2.17.3.patch| 34 +++
.../repo/repo/0001-python3-shebang.patch
From: Jasper Orschulko
Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/conf/distro/include/maintainers.inc | 1 +
.../0001-Set-REPO_REV-to-v2.17.3.patch| 34 +++
.../repo/repo/0001-python3-shebang.patch
From: Jasper Orschulko
Add git-native and repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..3298bd1952
Hi Alex,
> that you invented a custom, proprietary
> workflow that you have to support entirely by > yourselves
We are not though. We are integrating an established tool for multi-repository
management into yocto. Google repo is not proprietary by the way, it is
permissive licensed. It is
From: Jasper Orschulko
Add git-native and repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..3298bd1952
From: Jasper Orschulko
Add a recipe for repo, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
.../repo/files/0001-python3-shebang.patch | 21
.../0001-Set-REPO_REV-to-v2.17.3.patch| 33 +++
meta/recipes-devtools/repo/repo.inc
From: Jasper Orschulko
Add git-native and repo-native as prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
meta/classes/base.bbclass | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1d..3298bd1952
From: Jasper Orschulko
Add a recipe for repo, prerequisite for the repo fetcher.
Signed-off-by: Jasper Orschulko
---
.../repo/files/0001-python3-shebang.patch | 21
.../0001-Set-REPO_REV-to-v2.17.3.patch| 33 +++
meta/recipes-devtools/repo/repo.inc
From: Martin Koppehel
Setting latest_revision contained a race condition, where it would be
set to an empty string, if the hash calculation function would take to
long.
Signed-off-by: Jasper Orschulko
---
lib/bb/fetch2/__init__.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
From: Martin Koppehel
- Implement AUTOINC and submodule support for REPO provider
- Implement full srcrev support
- Add comments and fixup empty DL_DIR initialization
- Distinguish between artificial and plain rev
- Comments/documentation
The previous implementation of the repo fetcher could
https://lists.x.org/archives/xorg-announce/2021-May/003088.html
XLookupColor() and other X libraries function lack proper validation
of the length of their string parameters. If those parameters can be
controlled by an external application (for instance a color name that
can be emitted via a
Obviously, patch files in patch files still confuse me... :D v3 on it's way!
On 22 June 2021 16:30:40 CEST, Steve Sakoman wrote:
>On Tue, Jun 22, 2021 at 2:09 AM Jasper Orschulko via
>lists.openembedded.org
>wrote:
>>
>> https://lists.x.org/archives/xorg-announce
https://lists.x.org/archives/xorg-announce/2021-May/003088.html
XLookupColor() and other X libraries function lack proper validation
of the length of their string parameters. If those parameters can be
controlled by an external application (for instance a color name that
can be emitted via a
https://lists.x.org/archives/xorg-announce/2021-May/003088.html
XLookupColor() and other X libraries function lack proper validation
of the length of their string parameters. If those parameters can be
controlled by an external application (for instance a color name that
can be emitted via a
e
>
>On Mon, Jun 21, 2021 at 4:11 AM Jasper Orschulko via
>lists.openembedded.org
>wrote:
>>
>> There's a flaw in libxml2 in versions before 2.9.11. An attacker who
>is able to submit a crafted file to be processed by an application
>linked with libxml2 could trigger a
There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able to
submit a crafted file to be processed by an application linked with libxml2
could trigger a use-after-free. The greatest impact from this flaw is to
confidentiality, integrity, and availability.
Upstream-Status:
There's a flaw in libxml2 in versions before 2.9.11. An attacker who is able to
submit a crafted file to be processed by an application linked with libxml2
could trigger a use-after-free. The greatest impact from this flaw is to
confidentiality, integrity, and availability.
Upstream-Status:
43 matches
Mail list logo
