On Thu, 2021-03-25 at 21:16 -0400, Mark H Weaver wrote:
>
> Looks good to me. Please push. Thank you!
>
> Mark
Thank you for the review, pushed as
52c8d07a4f7033534a71ac7efeec21a65d35c125.
signature.asc
Description: This is a digitally signed message part
$ ./pre-inst-env guix refresh exiv2
gnu/packages/image.scm:1343:2: warning: 'generic-html' updater failed
to determine available releases for exiv2
It seems applying this patch does not help either:
diff --git a/gnu/packages/image.scm b/gnu/packages/image.scm
index d04a247976..8ede48eea5 100644
On Fri, 2021-03-26 at 00:24 +0100, Ludovic Courtès wrote:
> Léo Le Bouter skribis:
>
> > Full log: https://ci.guix.gnu.org/build/117996/log/raw
>
> Speaking of which: please always build packages before pushing. :-)
>
> Thanks,
> Ludo’.
I ran 'guix pull' but turn
v3 tested and builds fine:
$ ./pre-inst-env guix build mariadb
/gnu/store/f70jymwyfcnsghy4jg8caibci59p8rgq-mariadb-10.5.8-dev
/gnu/store/cj3qym1x1jjh02m2g23cqpbhchrbmn6c-mariadb-10.5.8-lib
/gnu/store/mpb5bdf1vkwazqfmmwcvskdm50g191bg-mariadb-10.5.8
Since we don't have PoC, I can't verify the
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
On Fri, 2021-03-19 at 12:35 +0100, zimoun wrote:
> Instead of grafting, I would fix first check the compatibility
> between
> mariadb and zstd. Because mariadb@10.5.8 does not build with
> zstd@1.4.9, at least on my machine.
Can you post build logs and repro scenario? mariadb@10.5.8 built fine
* gnu/packages/patches/mariadb-CVE-2021-27928.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/databases.scm (mariadb/fixed): New variable. Apply patch.
(mariadb)[replacement]: Graft.
---
gnu/local.mk | 1 +
FAIL: tests/print
=
test-name: simple package
location: /tmp/guix-build-guix-1.2.0-18.86dd54f.drv-
0/source/tests/print.scm:70
source:
+ (test-equal
+ "simple package"
+ `(define-public test ,pkg-source)
+ (package->code pkg))
expected-value: (define-public test (package
("guile" ,guile-3.0-latest)
It worked fine.
Is that enough of a test to graft in master?
Let me know and I will push.
Léo
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-03-25 at 00:08 +0530, Dhruvin Gandhi wrote:
> Hello Guix,
>
> I've been working on building latest zig compiler toolchain (0.7.1)
> following Simon Nielsen's work (bug#39480 for 0.5.0).
>
> The compiler builds correctly. But it fails during the install phase.
> It is able to copy
On Wed, 2021-03-24 at 21:24 +0100, Vincent Legoll wrote:
> Hello,
>
> On Wed, Mar 24, 2021 at 8:51 PM Leo Famulari
> wrote:
> > > We bought a handful of Overdrive 1000 in the past (they are no
> > > longer
> > > sold), and hosting was always an obstacle.
> >
> > I volunteer to host one or two
It seems this is due to guile 3.0.5, GNU Shepherd 0.8.1 does not work
with it, it works with guile 3.0.2 however.
Thanks to Efraim on IRC for hints.
It would be great if people knowledgeable with Scheme, GNU Shepherd and
Guile could fix it, it blocks GNOME upgrade work on top of core-
updates.
On Tue, 2021-03-23 at 23:41 -0700, Chris Marusich wrote:
> Hi,
>
> FYI, I have merged wip-ppc64le-for-master to master and closed bug
> 47182. I have also deleted the wip-ppc64le-for-master branch.
>
> Later this week, I will update the manual to mention that
> powerpc64le-linux is supported,
One more:
CVE-2021-20227 23.03.21 18:15
A flaw was found in SQLite's SELECT query functionality (src/select.c).
This flaw allows an attacker who is capable of running SQL queries
locally on the SQLite database to cause a denial of service or possible
code execution by triggering a
CVE-2021-20270 23.03.21 18:15
An infinite loop in SMLLexer in Pygments
versions 1.5 to 2.7.3 may lead to denial of service when performing
syntax highlighting of a Standard ML (SML) source file, as demonstrated
by input that only contains the "exception" keyword.
Upstream version 2.8.1 is not
I pushed a9d540cfa87ef3a5de3296188f650fb0d037efbd on core-updates, how
to fix it on master considering the amount of dependents remains to be
agreed on.
signature.asc
Description: This is a digitally signed message part
to be in this maintained state, for example, in the GNU Guix System
configuration.
Some kind of quality rating for packages that users can trust.
What do you think?
Léo
signature.asc
Description: This is a digitally signed message part
* gnu/packages/xml.scm (java-mxparser): New variable.
---
gnu/packages/xml.scm | 28
1 file changed, 28 insertions(+)
diff --git a/gnu/packages/xml.scm b/gnu/packages/xml.scm
index 2a72fc6ad2..96287b3174 100644
--- a/gnu/packages/xml.scm
+++ b/gnu/packages/xml.scm
@@
Upstream has made a release: 1.4.16 - which fixes all the issues,
following is an unfinished patchset that fixes the issues, java-
mxparser package does not build and help from some more experienced
Java packagers is welcome to fix and push this patchset.
signature.asc
Description: This is a
erge with
master, but I am afraid this enters in conflict with people not having
lots of bandwidth to download a new world again through substitutes or
very powerful machines for those who don't use substitutes.
Léo
signature.asc
Description: This is a digitally signed message part
Fixes CVE-2021-21341, CVE-2021-21342, CVE-2021-21343, CVE-2021-21344,
CVE-2021-21345, CVE-2021-21346, CVE-2021-21347, CVE-2021-21348,
CVE-2021-21349, CVE-2021-21350 and CVE-2021-21351.
* gnu/packages/xml.scm (java-xstream): Update to 1.4.16.
[inputs]: Replace java-xpp3 with java-mxparser, the
On Tue, 2021-03-23 at 14:42 +0100, Ludovic Courtès wrote:
> Like Efraim wrote, the person who makes the release (I’m afraid it’ll
> be
> me) needs to be able to offload to a “trustworthy” machine for that
> platform.
>
> If we can do that, we should adjust the ‘release’ target in
> ‘Makefile.am’
rks AFAICT, but it's not widely known how it can be
used and why.
What do you think?
Léo
signature.asc
Description: This is a digitally signed message part
In general my opinion is that backporting fixes is time-consuming and
that if we have to do it each time I wont be able to keep up with the
load. I'd rather update things to a version that already includes fixes
and is supported by upstream even at the cost of world rebuilds. I
can't deal with
/2d01a1ba8984e0483ce6619b972832377f208a0d
), so we should probably upgrade to that.
Has lots of dependents so I suppose it needs grafting? Is that useful
and does it work for Python packages?
Léo
signature.asc
Description: This is a digitally signed message part
> I do agree though that it would be nicer to just have '-' as a guix
> input arg causing any guix command to read from stdin.
Doesnt /dev/stdin work?
The only reason it could not is that somehow the file descriptor needs
to be seekable.
Léo
signature.asc
Description: This is a dig
Also are there actually people using the
mongodb service on GNU Guix?
> What do the previous
> contributors to this code think—Chris, Efraim, Marius, Arun?
Chris voiced their opinion saying they didnt mind removing the package,
I think Efraim said that on IRC also but I am not sure, so let's
/guix/drvs/hk/1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv.bz2'.
guix build: error: build of
`/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed
Léo Le Bouter (1):
gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].
gnu/packages/databases.scm | 33 +
1 file changed, 33 insertions(+)
--
2.31.0
* gnu/packages/databases.scm (mariadb/fixed): New variable.
(mariadb)[replacement]: Graft.
---
gnu/packages/databases.scm | 33 +
1 file changed, 33 insertions(+)
diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 8be83f5cbe..6fdb22d7fb
@7.1.2
Do we remove it? Do we want to commit to backporting/applying all fixes
from python-pillow back in python-pillow-simd ourselves (I don't)?
Léo
signature.asc
Description: This is a digitally signed message part
AIUI. I am not sure we could actually update
individual outputs right now though. Might be a good idea to split the
packages for the future.
Léo
signature.asc
Description: This is a digitally signed message part
not help.
The release area has a folder with version and then a tar.gz with
version inside it's name as well, not sure if generic-html updater
supports that.
See: https://mediaarea.net/download/source/mediainfo/
Thank you!
Léo
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-03-18 at 21:41 +0100, Ludovic Courtès wrote:
> I think it’s more of a discussion for guix-devel than a bug
> report. :-)
Yes but then I was thinking how do we track progress without losing it
in the pile of emails from guix-devel people receive everyday which
made me create a bug in
all commits and then it
means we would have to apply patches for each and every CVE which can
be tedious to create and maintain and to me leaving the package as-is
without patching is not really OK :-/
To graft or not to graft?
Thank you,
Léo
signature.asc
Description: This is a digitally signed
likely if
we have to dig commit history manually).
If nobody can put time to dig patches for all individuals CVEs until we
ungraft then I'd rather have this scary commit in.
Léo
signature.asc
Description: This is a digitally signed message part
Fixed by 1155a88308df7649fe74bd5bb8279a4d103ce386
signature.asc
Description: This is a digitally signed message part
Thanks a lot to the reporter and for working on this!
signature.asc
Description: This is a digitally signed message part
on improving that
process.
Attached WIP patch.
Thank you!
Léo
From b0f9566e9ff9a5f409a3fd4293c048ec58bc770d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?L=C3=A9o=20Le=20Bouter?=
Date: Thu, 18 Mar 2021 07:09:10 +0100
Subject: [PATCH] gnu: sqlite: Update to 3.32.3 [security fixes].
* gnu/packages/sqlite.scm
) to run the test suite WITH
the graft. This could be turned on by GNU Guix contributors after
trying to graft some package to ensure it does not break things.
What do you think?
Léo
signature.asc
Description: This is a digitally signed message part
(might actually run code from
the binary) or objdump -x (pure static analysis), so after grafting we
could check that every binary can load all it's dependents declared in
the ELF headers successfully and report errors if not?
What do you think?
Léo
signature.asc
Description: This is a digitally
On Wed, 2021-03-17 at 04:05 -0400, Mark H Weaver wrote:
> I've made an attempt to improve this situation in commit
> 1a265842e634656411bc7304c4648273f174f65e on the 'master' branch.
> Especially note the changes made in guix/build-system/python.scm.
>
> You might find that commit
We could do it without cloning the repos, for example the "fennel"
package:
$ git ls-remote --tags https://git.sr.ht/~technomancy/fennel
e54a85b3525a44ac16d6a4e35d19a1d5d6948ce2refs/tags/0.1.0
5c58b24f5261734caff25b9cbe2e8b551027a8bdrefs/tags/0.1.1
After applying:
diff --git a/gnu/packages/lua.scm b/gnu/packages/lua.scm
index edb3f85109..36fd1eb066 100644
--- a/gnu/packages/lua.scm
+++ b/gnu/packages/lua.scm
@@ -1175,6 +1175,8 @@ enabled.")
(snippet
'(begin
(delete-file "fennelview.lua")
On Wed, 2021-03-17 at 19:51 +0100, zimoun wrote:
> It shows exactly my point. The correct and polite way of doing the
> thing is first to examine the issue at hand (3.4.10 is old with
> security
> vulnerabilities), then propose a fix (e.g., the removal), wait
> feedback,
> and complete.
Actually
"-march=native" to CFLAGS
(breaking reproducibility).
Léo
signature.asc
Description: This is a digitally signed message part
The issue with 3.4.24 / 3.4.10 is that Efraim reverted the commit then
it was briefly discussed on IRC and Efraim thought I was right about
the licensing being fine on 3.4.24 and reverted their revert commit,
after some actual checking in the tarball grepping for license headers
I found out I was
I applied such patch:
diff --git a/gnu/packages/sqlite.scm b/gnu/packages/sqlite.scm
index eeb77749d8..35cf0168e0 100644
--- a/gnu/packages/sqlite.scm
+++ b/gnu/packages/sqlite.scm
@@ -65,6 +65,8 @@
(sha256
(base32
On Wed, 2021-03-17 at 18:30 +0100, raingloom wrote:
> I'm re-reading the threads about Rust packaging and I realized there
> might be a solution to the build artifact reuse problem.
>
> As I understand it, the problem is that crates can be compiled with
> any
> number of features enabled or
-revert the revert to
restore 3.4.10 instead so we get rid of the non-free code issue. Does
anyone actually use MongoDB on GNU Guix? Some people don't look at
versions or when they were released and just trust GNU Guix.
>
> All the best,
> simon
Léo
signature.asc
Description: This is a digitally signed message part
On Wed, 2021-03-17 at 18:35 +0100, Ludovic Courtès wrote:
> Established distros have great tools and services for that.
>
> Guix has ‘guix refresh’, which predates some of the trendy
> release/CVE
> monitoring services and actually works well. It’s not perfect, but
> it’s
> good, so my advice
Sorry for duplicated email,
On Wed, 2021-03-17 at 17:56 +0100, zimoun wrote:
> If the removal for security reasons had been discussed on IRC, it
> could
> be nice to point the discussion here. Otherwise, open a discussion
> on
> the topic on guix-devel or bug-guix. The full removal is a radical
te was reverted, then the revert was reverted due to
debate on licensing which turns out reverting the revert was actually
wrong because some specific files were under SSPL, at that point we
were shipping SSPL code which is nonfree, so the removal is also that.
Nonfree code + security issue m
Just as a reminder siding with vagrantc here:
We must ensure the Debian 'guix' package can still work and upgrade
from it's installed version, so ensure that removing gzip doesnt break
initial 'guix pull' with it.
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-03-16 at 23:28 +, Christopher Baines wrote:
> I did spot these patches
> https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=7298
Awesome!! I did not see them earlier!
> I think the Guix Data Service could run the "refresh" code from Guix
> and
> store
On Tue, 2021-03-16 at 21:53 +0100, Tobias Geerinckx-Rice wrote:
> Hi L[ée]o,
>
> Wow, Léo. You've done some seriously impressive CVE squashing in
> such a short timespan, and I'm very grateful to have you on board.
I spent few days on this, it's not that much! I did not do much w
On Tue, 2021-03-16 at 22:46 +0100, Bengt Richter wrote:
> I would feel better about running guix on my laptop if I
> knew all you developers had gotten together and elected
> a "security czar" who is the most competent of you to monitor
> security and also cares the most, and had the power to
ration files that allow executing arbitrary code, also
GNU Guile seems to have a sandboxed evaluation mode, that's good. I
like the freedom of arbitrary code evaluation anywhere gives us, but I
also want to make sure it's actually secure to do so.
Léo
signature.asc
Description: This is a digi
quot;, "guix-ugly" or
"guix-love-me-please".
Léo
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-03-16 at 19:46 +0100, zimoun wrote:
> Well, it seems better to send such changes to guix-patches, waiting
> 15
> days, and then if no comment, push. It is what the manual describes:
>
> Non-trivial patches should always be posted to
> guix-patc...@gnu.org (trivial
env guix refresh -l zstd@1.4.4
Building the following 5115 packages would ensure 10443 dependent
packages are rebuilt
[...]
There we are, almost all packages need to be rebuilt.
Léo
signature.asc
Description: This is a digitally signed message part
se types of
> patches should be reviewed on guix-patches. Léo, can you send them to
> guix-patches in the future?
>
> Sometimes it is okay to update things in a graft, but it depends on
> the
> situation.
1.4.4 and 1.4.9 are ABI compatible? At least that's the reason I
b
ause we
lived with something that we should live with it longer, I don't want
unpatched zstd (or any other) CVEs on my system. Actually I am not sure
1.4.4 had any CVE before that one though, so that must also be why.
Léo
signature.asc
Description: This is a digitally signed message part
I suggest we disable the test-suite or the specific test in the interim
for other architectures.
The CVE-2021-24032 is Base Score: 9.1 CRITICAL - which is exceptionally
high so fixing it is an absolute necessity in any branch.
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-03-16 at 13:57 +0100, Konrad Hinsen wrote:
> With Guix commit (ab9629b7c91ff7d6392a03512cfe44282326), building
> git fails because of a hash mismatch when downloading the man pages
> (see
> log below).
>
Yes, this is fixed by 0ee5d4f7a8e25be437297f88ed7013c4f37abafb, simply
On Tue, 2021-03-16 at 12:12 +0100, Ricardo Wurmus wrote:
> Léo Le Bouter writes:
>
> > I am thinking we should really get something like this with the
> > Guix
> > Data Service, start including something similar to Debian
> > uscan/watch
> > rules in
On Tue, 2021-03-16 at 12:17 +0100, Jonathan Brielmaier wrote:
> I think the only two reasons against that are: time and
> CI/rebuilding. I
> think thats the reason why stuff like Gnome and others lower in the
> dependency tree are lacking behind... Being non-FHS and non-systemd
> makes updates for
even when it
requires us to do more far-reaching changes because of
dependents/dependencies.
Let me know what you think!
Léo
signature.asc
Description: This is a digitally signed message part
tter.scm) and trying to build it and all it's
dependents and if it doesnt cause any new failures we could send an
automated patch contribution on guix-patches directly and tag it with
"ci-update-ok" or something so a maintainer just has to double-check
quickly and push (very efficien
./pre-inst-env guix lint -c cve python-urllib3@1.26.2
Here this should return at least CVE-2021-28363 but it does not because
the CVE database contains urllib3 and not python-urllib3 (which AFAICT
the cve linter searches for).
Annotating each and every python-, go-, and rust- package with
NOTE: SecureBoot on GNU Guix is not something common at all, so the
urgency to fix this issue is not as great as if we explicitly
advertised support for SecureBoot.
signature.asc
Description: This is a digitally signed message part
As outlined by:
-
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=a01bfa7deed1d556fc75ab5588517442054bc5a9
-
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=db87d6ddafd26c5ad657178cf7fdab524d05c522
Two commits needed to be made to fix the issue both in the python2 and
python3
On Tue, 2021-03-16 at 09:08 +0100, Léo Le Bouter via Bug reports for
GNU Guix wrote:
> There is no new upstream release so patching this appears to be some
> kind of sport.
There seems to be a release candidate available:
https://lists.gnu.org/archive/html/grub-devel/2021-03/msg0021
On Tue, 2021-03-16 at 09:08 +0200, Efraim Flashner wrote:
> On Mon, Mar 15, 2021 at 09:03:04PM -0700, Chris Marusich wrote:
> > How shall we build the binary tarball for the release? Of course,
> > anybody with a copy of the (source) release tarball can build their
> > own
> > guix binary by
As outlined by
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass2021
we have a new wave of GRUB security vulnerabilities around SecureBoot.
There is no new upstream release so patching this appears to be some
kind of sport.
Debian has patched it in this commit:
Some tests fail:
FAIL: tests/no-home.sh
FAIL: tests/status-sexp.sh
PASS: tests/misbehaved-client.sh
FAIL: tests/replacement.sh
PASS: tests/file-creation-mask.sh
PASS: tests/restart.sh
PASS: tests/one-shot.sh
FAIL: tests/basic.sh
PASS: tests/respawn-throttling.sh
PASS: tests/signals.sh
PASS:
: error: parse-datetime.c: No such file or directory
gcc: fatal error: no input files
compilation terminated.
This file seems to be generated by YACC from earlier log.
Léo Le Bouter (1):
gnu: patch: Update to 2.7.6-7623b2d [security fixes].
gnu/packages/base.scm | 39
* gnu/packages/base.scm (patch/fixed): New variable.
(patch)[replacement]: Graft.
---
gnu/packages/base.scm | 39 +++
1 file changed, 39 insertions(+)
diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index 9aa69cfe77..a71b47ac4f 100644
---
Thanks a lot! Keep it up! :-D
signature.asc
Description: This is a digitally signed message part
Thanks a lot! Keep it up! :-D
signature.asc
Description: This is a digitally signed message part
Exciting new possibilities! Great work!
signature.asc
Description: This is a digitally signed message part
Hello!
Latest version is 89.0.4389.90
ungoogled-chromium upstream has it:
https://github.com/Eloston/ungoogled-chromium/commit/64cbcbcfee33fd56760173b3a17d2de52cd77258
Debian also upgraded:
https://salsa.debian.org/chromium-team/chromium/-/commit/8a1f530bdc3fc90993cdc1499e77f9e91468a686
I am
don't forget things and
can come back later, and if I disappear, other people can still have a
go at them.
Léo
signature.asc
Description: This is a digitally signed message part
CVE-2021-20232 12.03.21 20:15
A flaw was found in gnutls. A use after free issue in
client_send_params in lib/ext/pre_shared_key.c may lead to memory
corruption and other potential consequences.
It is not certain whether 3.6.x series are affected as packaged in GNU
Guix. I asked the upstream at
CVE-2021-28302 12.03.21 16:15
A stack overflow in pupnp 1.16.1 can cause the denial of service
through the Parser_parseDocument() function. ixmlNode_free() will
release a child node recursively, which will consume stack space and
lead to a crash.
Upstream did not provide a patch yet, see <
On Fri, 2021-03-12 at 01:47 -0500, Mark H Weaver wrote:
> Thanks. I backported the upstream fix, and pushed it to 'master' in
> commit 5a06b83fc92710c5846a83bbf49f0ea84c8ecec2.
>
> Mark
Many thanks to you!!
signature.asc
Description: This is a digitally signed message part
again it seems?
Thank you,
Léo
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-03-11 at 06:23 -0500, Mark H Weaver wrote:
> Mark H Weaver writes:
>
> > As I wrote in another thread: I'll backport the fixes for CVE-2021-
> > 27218
> > and CVE-2021-27219 to our version of Glib, based on the backports
> > already published by Ubuntu for Glib 2.56.4 and 2.64.4.
>
On Thu, 2021-03-11 at 10:58 +0100, zimoun wrote:
> Well, IMHO 1) «not durable» could mean months and 2) disabling all
> the
> tests for all the architectures is wrong especially when only one
> test
> is failing for only one architecture.
I know that, I was tired yesterday and didnt want to block
On Thu, 2021-03-11 at 10:37 +0100, zimoun wrote:
> This disable the complete test suite for all the architecture. I
> have
> not look into the details but it seems better to only disable the
> offending test only the architecture affected.
Yes it does that and it would be better not to but zstd
Just wanted to say, Chris, thank you so much for following up steadily
on this powerpc64le-linux work. I have been testing your changes on and
off but without getting to actually solving issues as I have been busy
with other things unrelated with GNU Guix and also GNU Guix CVE
patching now.
On Thu, 2021-03-11 at 03:18 -0500, Mark H Weaver wrote:
> Hi Léo,
Hello!
> I appreciate your recent work on Guix security. Thank you for that.
Very happy to catch up there as well for my own usage of GNU Guix as
well!
> Can you please substantiate this? What vulnerabilities do
security fixes for that version is available.
What can we do about this you think?
Léo
signature.asc
Description: This is a digitally signed message part
afford to spend time backporting security fixes to
the numerous GNOME packages with CVEs, not with current resources, it
is time-consuming.
Léo
signature.asc
Description: This is a digitally signed message part
CVE-2021-21375 00:15
PJSIP is a free and open source multimedia communication library
written in C language implementing standard based protocols such as
SIP, SDP, RTP, STUN, TURN, and ICE. In PJSIP version 2.10 and earlier,
after an initial INVITE has been sent, when two 183 responses are
the graft.
At least this fixes the issue, if anyone wants to still enable tests,
feel free, no energy for that myself now.
This will do while we wait for an upstream patch.
Léo
signature.asc
Description: This is a digitally signed message part
This is GNOME Orca in the CPE database:
https://nvd.nist.gov/products/cpe/detail/660937?namingFormat=2.3=CPEURI=orca=FINAL
Currently CVE-2020-9298 is being wrongly reported by 'guix lint -c cve'
because vendor is not taken into account, therefore:
"cpe:2.3:a:spinnaker:orca" also matches.
/-/merge_requests/1942 (CVE-2021-
27218)
- https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1944 (CVE-2021-
27218)
- https://gitlab.gnome.org/GNOME/glib/-/issues/2319 (CVE-2021-27219)
Léo
signature.asc
Description: This is a digitally signed message part
operability, mixing packages, etc?
I don't think so, not in particular.
> Cheers,
> Yasu
Léo
signature.asc
Description: This is a digitally signed message part
On Wed, 2021-03-10 at 12:32 -0500, Leo Famulari wrote:
> Well, we could also just remove this package. It sounds like it is
> not
> supported on Linux. Does it offer some unique functionality?
I would advocate for removal of the package, or at least warning about
absence of security patches for
On Wed, 2021-03-10 at 11:37 +0100, Ludovic Courtès wrote:
> Hi Léo,
Hi Ludo!
> So I think there’s a genuine bug here. Could you take a look? At
> worst, we should skip the offending test on i686 (and perhaps
> ARMv7?).
I reported upstream and I got an answer, waiting for fix but a
201 - 300 of 1128 matches
Mail list logo
