Hi,
As I found no convenient solution, I will try to write a small module that
adress this problem. It will be a good occasion to discover Elisp :). It is
thought as an alternative to org-special-latex-block: efficient
fontification using default face, folding environment to hide proofs,
pretty
à 15:03, Eric S Fraga a écrit :
> On Tuesday, 22 Jun 2021 at 14:32, Léo Ackermann wrote:
> > Do you see what I mean ?
>
> I do but I guess I must have a differently configured system as I do not
> see any special fortification due to being in a special block.
>
> Howe
so on...
Do you see what I mean ?
Best,
Le mar. 22 juin 2021 à 14:13, Eric S Fraga a écrit :
> On Tuesday, 22 Jun 2021 at 13:20, Léo Ackermann wrote:
> > I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
> > and other org-latex-special-block are treated a
Hi all,
Many thanks for those advices!
I am new to org-mode but, is there a reason why #+BEGIN_proof #+END_proof
and other org-latex-special-block are treated as block ?
I mean; those #+... aim, as far as I understand, to give tips to org-export
for prettier exports but nothing else (between
Hi both!
Thanks a lot for your answers, it looks pretty now :)
Best,
Leo
Le mar. 1 juin 2021 à 10:43, Timothy a écrit :
> Hi Léo,
>
> For what it’s worth, I currently make do with:
>
> (setq org-highlight-latex-and-related '(native script entities))(add-to-list
> 'org-src-bl
Hi,
When it comes to preview inline LaTeX fragments within org-mode, the org
package applies the `org-block` face. It would be nice to *treat inline
latex block specially*, to make integration of the those preview-block
easier when surrounded by plaintext. This feature would allow to have a
theme
https://bugs.kde.org/show_bug.cgi?id=375951
Léo changed:
What|Removed |Added
CC||josephlegran...@gmail.com
--
You are receiving
Hello Tobias,
On Sat, 2021-05-01 at 04:34 +0200, Tobias Geerinckx-Rice wrote:
> Léo,
>
> Leo Le Bouter 写道：
> > I feel like what has happened is really a disaster,
>
> I'm relieved that we share, at least, this. I think everyone
> does.
>
> > I don't feel like
On Thu, 2021-04-29 at 13:46 +0200, Leo Prikler wrote:
> Am Donnerstag, den 29.04.2021, 11:13 +0200 schrieb Léo Le Bouter:
> > On Wed, 2021-04-28 at 17:52 +0200, Marius Bakke wrote:
> > > Léo,
> > >
> > > We maintainers have been disappointed by Marks harsh tone
ost every sentence that I wrote was
> purely
> factual. It seems to me that the facts speak for themselves, and
> those
> facts naturally cast Raghav and Léo in a bad light. I don't see how
> to
> avoid that while still presenting the facts.
>
> You, and a couple of others
On Wed, 2021-04-28 at 17:52 +0200, Marius Bakke wrote:
> Léo,
>
> We maintainers have been disappointed by Marks harsh tone which do
> not
> meet the project's communication standards, but also by your apparent
> lack of will to reply constructively to legitimate criticism.
>
nfident that the security fixes would have been
> reinstated on core-updates if Mark had not asked about them.
>
> Léo and Raghav, you need to keep learning our workflow around
> security
> updates. It's not okay to remove security patches and later update a
> package to a fixed
On Mon, 2021-04-26 at 17:23 +0200, Tobias Geerinckx-Rice wrote:
> Hi Léo,
>
> > https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
> > https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> >
> > Can you
On Sat, 2021-04-24 at 03:46 -0400, Mark H Weaver wrote:
> Hi Léo,
>
> Léo Le Bouter writes:
>
> > On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> > > Léo and Raghav, you need to keep learning our workflow around
> > > security updates. It's
On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> Léo and Raghav, you need to keep learning our workflow around
> security
> updates. It's not okay to remove security patches and later update a
> package to a fixed version in a different commit. `git rebase` is the
>
On Fri, 2021-04-23 at 13:52 -0400, Maxim Cournoyer wrote:
> Actually, there *is* a "new" stable release available on their
> release
> page, 1.17.2 [0]
>
> According to NVD [1], that latest version has no known CVE [1].
>
> Léo, could it be that yo
On Thu, 2021-04-22 at 13:40 -0400, Mark H Weaver wrote:
> This commit was digitally signed and pushed to the 'wip-gnome' branch
> by
> Raghav, but it's also "Signed-off-by: Léo Le Bouter", so I'm not sure
> who bears primary responsibility for this one.
It seems you are
On Thu, 2021-04-22 at 00:08 -0400, Mark H Weaver wrote:
> Hi Raghav,
>
> Raghav Gururajan writes:
>
> > > Those commits on 'core-updates' were digitally signed by Léo Le
> > > Bouter
> > > and have the same problems: they remove
> > > security
On Thu, 2021-04-15 at 10:00 +, bo0od wrote:
> Guix need to improve itself when first time initiated, Please check
> other projects like NixOS,Triskel,Mint,Ubuntu...etc
>
>
> If you dont like that live graphical gui access, then do it as debian
> is
> doing it which give you proper gui
n
name.
I am not sure this is the cause, since shepherd is wrapped to use GNU
Guile 3.0.2.
I am also still looking for a solution.
Léo
signature.asc
Description: This is a digitally signed message part
nt I
> > believe it will automatically show up on the blog.
>
> I have published it in commit
> 0129dd529347bfefee96644ac9fbabc29adbe772.
> Thank you again to everyone for your help!
>
Awesome! I also sent an email to Micheal from Phoronix earlier, but it
seems t
On Thu, 2021-04-08 at 20:01 -0400, Leo Famulari wrote:
> On Tue, Apr 06, 2021 at 06:51:47PM -0400, Leo Famulari wrote:
> > Yeah. Given this report, we could also just build Syncthing with
> > the
> > bundled source code, which is freely licensed.
>
> I've attached the patch.
I tested this patch
On Fri, 2021-04-09 at 15:25 +0200, Nicolò Balzarotti wrote:
> Léo Le Bouter writes:
>
> > Hello!
>
> Hi!
> > I have been feeling considerable amount of stress reviewing CVE
> > entries
> > alone, these days I want to focus on other things and I've been
Hello!
I have been feeling considerable amount of stress reviewing CVE entries
alone, these days I want to focus on other things and I've been feeling
held back because I abandonned the CVE entries reviewing task without
anyone doing it when I'm not here.
Right now at time of sending this email,
On Wed, 2021-04-07 at 17:00 +0200, Andreas Enge wrote:
> posting messages to the issues looks like a feasible and good thing
> to me,
> then all relevant information would be present in the same place.
I also think that's what should be done but it seems there are worries
that this may cause
Fixed by 2b605ef3b145ec136530f08ee7aa27382aa64b46
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-04-08 at 09:37 -0700, Chris Marusich wrote:
> They also say in that Twitter thread: "We have been putting together
> our
> systems from blob-free components only (sans NIC as is known and
> being
> actively worked), and this is an area where no low-cost blob-free
> silicon is
On Tue, 2021-04-06 at 00:15 -0700, Chris Marusich wrote:
> Hi,
>
> Léo and I have drafted the following blog post. Could you take a few
> minutes to read it and give us your thoughts?
>
> It's a work in progress. The primary goal is to announce the new
> powerpc64le-linu
On Tue, 2021-04-06 at 20:21 +0300, Andrew Tropin wrote:
> Guix Home has most essential features ready and now requires some
> real-world usage from a few more people to be sure that there are no
> fundamental issues with it.
>
> We are looking for 3-5 advanced GNU/Linux users (not necessary
/45476
Léo
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-04-06 at 17:27 -0400, Mark H Weaver wrote:
> Hi Léo,
>
> Léo Le Bouter writes:
>
> > I think that probably replacing arbitrary paths in built binaries
> > is a
> > risky and maybe unreliable engineering choice and that mechanisms
> > inside
addresses.
Can't find a corresponding package in GNU Guix.
To be continued!
Léo
signature.asc
Description: This is a digitally signed message part
, what would be wrong with replacing hashes directly without
expecting them to be next to anything else?
Léo
signature.asc
Description: This is a digitally signed message part
CVE-2021-30046 15:15
VIGRA Computer Vision Library Version-1-11-1 contains a segmentation
fault vulnerability in the impex.hxx read_image_band() function, in
which a crafted file can cause a denial of service.
Upstream issue: https://github.com/ukoethe/vigra/issues/494
No fix provided yet.
either
It would be best if Nettle adopted a forever (or almost) backwards
compatible ABI from now on like curl (https://curl.se/libcurl/abi.html)
so that such things don't happen again.
Thank you,
Léo
signature.asc
Description: This is a digitally signed message part
age but rather just link to ML/git/else.
We could write such policy at the top of the page so contributors to it
can easily see it.
What do you think?
Léo
signature.asc
Description: This is a digitally signed message part
the review process when
we would crucially need such help.
Thank you!
Léo
signature.asc
Description: This is a digitally signed message part
upstream released 2.11 which fixed the issue.
Update to 2.11 pushed as 45136b3673bcdba21fa0d1fd6edb3d388a645fcc
signature.asc
Description: This is a digitally signed message part
Upstream created and merged a probable patch:
https://github.com/pupnp/pupnp/pull/306
Reporter still needs to confirm if it fixes the issue.
signature.asc
Description: This is a digitally signed message part
Still no fix available from upstream (unclear)
signature.asc
Description: This is a digitally signed message part
263e4af90932ea36f596b
(PYTHONPATH more so)
-
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00c1793ce8e2210e48b18422ea3e76da10541874
(Append xdg-utils to PATH)
Let me know if there's any questions about creating such wrappers.
Léo
signature.asc
Description: This is a digitally signed message part
Fixed in dda88cda120d75f7d139e54367c0d76e574091dc
signature.asc
Description: This is a digitally signed message part
Hello!
Like 'guix edit hello' we could have 'guix system edit screen-locker'
for easy access to customize services.
What do you think? Is this hard to do?
Léo
signature.asc
Description: This is a digitally signed message part
It seems running 'make clean' then 'make check-system' again solved the
issue. Probably some build system inconsistency issue.
signature.asc
Description: This is a digitally signed message part
On Tue, 2021-03-30 at 10:26 +0200, Ludovic Courtès wrote:
> Hi!
>
> Léo Le Bouter skribis:
>
> > I don't want to give more access than what SSH non-root access
> > would
> > give, and I think it would be possible to do something helpful in
> > GNU
> > G
On Sat, 2021-04-03 at 17:47 +0200, Hartmut Goebel wrote:
> Am 17.03.21 um 19:23 schrieb Léo Le Bouter:
> > I advise you look there also:
> > https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rlib-intermediate-object-reuse/near/225653640
>
> Ac
here as well!
If I have a comment about the CVE mechanism is that it seems CPE
vendor/name labeling isnt done well or not fast enough in practice,
most flaws I fix they do not have CPE name and vendor specified. So I
wonder how to automate recognition of them here. I believe some could
try and parse the summary with natural language analysis but that also
seems quite imprecise.
Léo
signature.asc
Description: This is a digitally signed message part
age: unbound variable
hint: Did you forget `(use-modules (gnu ci))'?
make: *** [Makefile:6305: check-system] Error 1
I tried looking around I am not sure what the cause is.
Thanks,
Léo
signature.asc
Description: This is a digitally signed message part
On Fri, 2021-04-02 at 16:25 -0400, Leo Famulari wrote:
> I will keep this in mind, pending their reply.
>
> The ticket system automatically added the tag 'hardware/ampere-
> altra'.
> So, it may be a case of "we can have any CPU we want, as long as it's
> an
> Ampere ALTRA"... as Henry Ford said,
To me, that last patch is ready to merge.
Please push if you feel that's OK too, don't wait for me!
Thanks!
signature.asc
Description: This is a digitally signed message part
Fixes CVE-2021-22876 and CVE-2021-22890.
* gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/curl.scm (curl/fixed): New variable. Apply patch.
(curl)[replacement]: Graft.
---
gnu/local.mk
Fixes CVE-2021-22876 and CVE-2021-22890.
* gnu/packages/patches/curl-7.76-use-ssl-cert-env.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/curl.scm (curl/fixed): New variable. Apply patch.
(curl)[replacement]: Graft.
---
gnu/local.mk
On Fri, 2021-04-02 at 14:22 -0400, Leo Famulari wrote:
>
> Can we try grafting an "upgrade" to 7.76.0? In my experience, most
> curl
> upgrades are graftable.
>
> Curl's developers are very careful with their ABI and even maintain
> their own page on the subject:
On Thu, 2021-04-01 at 21:33 +, Luis Felipe wrote:
> I just sent a patch to include a link to the wiki in the Help page (
> https://issues.guix.gnu.org/47555).
>
> If the patch is applied, I can send a separate patch to update the
> Help menu as Vincent suggested:
>
> Help
> • GNU Guix Manual
* gnu/packages/patches/curl-CVE-2021-22876.patch,
gnu/packages/patches/curl-CVE-2021-22890.patch: New patches.
* gnu/local.mk (dist_patch_DATA): Register them.
* gnu/packages/curl.scm (curl): Apply patches.
---
gnu/local.mk | 2 +
gnu/packages/curl.scm
/commit/?h=core-updates=2e0b1b62e94b926041ca9af70537dd9b3ab64edf
but unfortunately since curl requires so many rebuilds it seems we can't use
such commit on master for now.
Léo Le Bouter (1):
gnu: curl: Fix CVE-2021-22876 and CVE-2021-22890.
gnu/local.mk | 2
CVE-2021-22890 01.04.21 20:15
curl 7.63.0 to and including 7.75.0 includes vulnerability that allows
a malicious HTTPS proxy to MITM a connection due to bad handling of TLS
1.3 session tickets. When using a HTTPS proxy and TLS 1.3, libcurl can
confuse session tickets arriving from the HTTPS proxy
CVE-2021-28165 01.04.21 17:15
In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and
11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a
large invalid TLS frame.
CVE-2021-28164 01.04.21 17:15
In Eclipse Jetty 9.4.37.v20210219 to 9.4.38.v20210224, the default
compliance
Another:
CVE-2021-20296 01.04.21 16:15
A flaw was found in OpenEXR in versions before 3.0.0-beta. A crafted
input file supplied by an attacker, that is processed by the Dwa
decompression functionality of OpenEXR's IlmImf library, could cause a
NULL pointer dereference. The highest threat from
r staging and prioritize security updates through
that branch while also committing to actually merging that branch on
schedule.
Léo
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote:
> Hi Léo,
>
[...]
> That’s fine. We have no deadlines, so stepping back from what feels
> like a heated discussion for a while and revisiting the points later
> comes at very little cost.
>
> Obviously, you don’t *
CVE-2021-29938 07:15
An issue was discovered in the slice-deque crate through 2021-02-19 for
Rust. A double drop can occur in SliceDeque::drain_filter upon a panic
in a predicate function.
Upstream PR: https://github.com/gnzlbg/slice_deque/pull/91
I suggest we wait for merge then update our
CVE-2021-29939 07:15
An issue was discovered in the stackvector crate through 2021-02-19 for
Rust. There is an out-of-bounds write in StackVec::extend if size_hint
provides certain anomalous data.
No fix released upstream yet:
https://github.com/Alexhuszagh/rust-stackvector/issues/2
Out of
Another wave it seems:
CVE-2021-3479 31.03.21 16:15
There's a flaw in OpenEXR's Scanline API functionality in versions before
3.0.0-beta. An attacker who is able to submit a crafted file to be processed by
OpenEXR could trigger excessive consumption of memory, resulting in an impact
to
do them my way, if they do them they do it their way, what else can
we do here?
>
> Please adjust accordingly.
I don't feel like that's entirely fair but I always strive to self-
improve.
> Thanks,
> Ludo’.
Léo
signature.asc
Description: This is a digitally signed message part
ople who started them. Not
everyone can handle the load of incoming mail in the ML. On the GNOME
40 upgrade for example I linked the mailing list thread on the wiki
page also. The wiki page is also more likely to get outdated if it
doesnt have great visibility on the GNU Guix official website,
icts becomes too much trouble we will probably give up (Raghav
probably) and there wont be any GNOME 40 upgrade.
> Would this be acceptable to you?
I don't even know anymore.
> Regards,
> Mark
Léo
signature.asc
Description: This is a digitally signed message part
I asked the maintainer to fix the issues because they were unfixed
since a while, they have done so recently:
https://git.savannah.gnu.org/cgit/cflow.git/commit/?id=b9a7cd5e9d4efb54141dd0d11c319bb97a4600c6
They have not made a recently, also it seems they fixed other issues
that could be
CVE-2021-3474 30.03.21 20:15
There's a flaw in OpenEXR in versions before 3.0.0-beta. A crafted
input file that is processed by OpenEXR could cause a shift overflow in
the FastHufDecoder, potentially leading to problems with application
availability.
Fix:
w process, first
with me reviewing changes as they happen, then as a whole also, because
we wont push anything to core-updates, master or else without review.
Léo
signature.asc
Description: This is a digitally signed message part
nd that's also why we are doing it this way.
I feel bad now that it seems like everyone assumes we are doing things
we are not.
Léo
signature.asc
Description: This is a digitally signed message part
ilities", every distro has prioritization for security updates,
I think it is the right thing to do, that's how I work with it and I
think it is right. If you don't agree then OK but I wont stop thinking
it's the right way to do things and that not prioritizing security
issues does not work.
me, because it
> would
> merely postpone the required review work until the end of the process
> when the branch is ready to be merged into Savannah. Moreover, it
> would
> likely reduce the quality of that review work.
>
> Does that make sense?
Not to me, the git v
such
patch in a timely manner because the backport was non-trivial and
security-sensitive also didnt want to risk failing to fix the flaw
because I don't have much expertise on it, Ubuntu now has done that
work and we can just use it.
Léo
signature.asc
Description: This is a digitally signed
in a timely manner because the backport was non-trivial and
security-sensitive also didnt want to risk failing to fix the flaw
because I don't have much expertise on it, Ubuntu now has done that
work and we can just use it.
Léo
signature.asc
Description: This is a digitally signed message part
particular situation probably we can work on
getting Raghav's commit access application approved then your concerns
will be sorted out as no other non-committer participant seemed to show
up.
Léo
signature.asc
Description: This is a digitally signed message part
On Sun, 2021-03-28 at 16:48 -0400, Mark H Weaver wrote:
> How is it more flexible than a "wip-*" branch on Savannah?
>
> Thanks,
>Mark
Because as the GNU Guix project we have no control on the forge to
catter it to our own needs, because there is bureaucracy involved with
approving
reason I upgraded the 'guix' package here was to fix 'guix
pull' from older installations on powerpc64le-linux machines of mine.
Léo
signature.asc
Description: This is a digitally signed message part
branches with associated continuous integration infrastructure for
development.
If anyone wants to participate, please reach to cbaines about access.
Léo
signature.asc
Description: This is a digitally signed message part
On Sat, 2021-03-27 at 16:42 +, Luis Felipe wrote:
> I'm fine with that too (for now). I can send that patch.
>
> The reason I didn't suggest that, though, is that the primary menu
> has already grown too big in my opinion. And, with the current
> design, the visibility of the primary menu
On Sat, 2021-03-27 at 15:54 +, Luis Felipe wrote:
> Or that, yes. I can send a patch to add a Wiki entry to the Help page
> instead of adding a "Wiki" item to the "About" menu.
I think we should be looking forward to including it in the primary
menu and not hidden in some submenu.
On Sat, 2021-03-27 at 16:41 +0100, Vincent Legoll wrote:
> I don't know if libreplanet's wiki meets Léo's requirements,
> but this is probably OK from a PoV of spam management.
I could create an FSF account with automated approval by email.
It seems I cannot create new pages, however it seems we
On Sat, 2021-03-27 at 15:44 +, Luis Felipe wrote:
> What do you think about adding a "Wiki" item to the "About" menu of
> the website linking to that Guix group on LibrePlanet? At least as a
> quick solution to try out.
I think this would be the best thing to do, however I don't know if I
can
On Sat, 2021-03-27 at 11:32 -0400, Joshua Branson wrote:
> Good point. Perhaps we should link to this wiki from the guix
> website?
I think that we should do that for this wiki resource to be really
useful. Widespread knowledge of the location is a must.
signature.asc
Description: This is a
On Sat, 2021-03-27 at 04:24 +0100, Léo Le Bouter wrote:
> Hello!
>
> If you look at https://ci.guix.gnu.org/eval/13652 you can see that
> the
> evaluation of the derivation seems completed but there's no pending
> builds.
>
> What is happening here?
>
> Thank you
On Sat, 2021-03-27 at 11:07 +0100, Vincent Legoll wrote:
> Hello,
>
> I'd like to reiterate my proposal to document our
> ongoing projects, maybe with a "WIP" page on the
> web site (even if I'm not a web guy, I volunteer
> the maintenance of it).
>
> * CI-built pinebook-pro images [1]
> * other
any
> time to rebuild? how many packages are rebuilt between 2
> merges? etc.
> Is it enough? If not, what could be done to improve? etc.
The question whether this is solved by a branch or by making pushing to
master directly big rebuilds more viable, that I do not know, but you
cannot put f
On Sat, 2021-03-27 at 09:27 -0400, Mark H Weaver wrote:
> Your patch looks good to me, but I've just posted an alternative
> patch
> set to 'guix-devel' which should enable us to keep ImageMagick
> up-to-date without grafting, and which fixes this security flaw and
> more.
>
>
Thanks for your feedback.
On Sat, 2021-03-27 at 13:29 +0100, zimoun wrote:
> And as I said elsewhere, “to me, security is important. But it's
> no less important than everything *else* that is also important!“, so
> personally I am not convinced that security updates deserve a special
> treatment
Hello!
If you look at https://ci.guix.gnu.org/eval/13652 you can see that the
evaluation of the derivation seems completed but there's no pending
builds.
What is happening here?
Thank you
signature.asc
Description: This is a digitally signed message part
On Sat, 2021-03-27 at 00:12 +0100, Maxime Devos wrote:
> This patch seems about right to me. However,
>
> $ guix lint -c cve imagemagick
> gnu/packages/imagemagick.scm:132:2: imagemagick@6.9.12-2g: probably
> vulnerable to CVE-2021-20176, CVE-2021-20243, CVE-2021-20244, CVE-
> 2020-25663,
aster directly when we feel it is
the right thing would be what I would like to do. Even if it causes big
world rebuilds, when we can't graft.
There's another thing I saw that was ongoing but can't remember where,
that 'guix pull' could hold off updating to newer revisions unless
substitutes are ava
Another:
CVE-2021-20284 18:15
A flaw was found in GNU Binutils 2.35.1, where there is a heap-based
buffer overflow in _bfd_elf_slurp_secondary_reloc_section in elf.c due
to the number of symbols not calculated correctly. The highest threat
from this vulnerability is to system availability.
CVE-2021-20193 18:15
A flaw was found in the src/list.c of tar 1.33 and earlier. This flaw
allows an attacker who can submit a crafted input file to tar to cause
uncontrolled consumption of memory. The highest threat from this
vulnerability is to system availability.
Patch available here:
just like that? Or must it be upgraded in
tandem with GCC and friends?
Thank you,
Léo
signature.asc
Description: This is a digitally signed message part
must provide a fix quickly.
What do you think?
Léo
signature.asc
Description: This is a digitally signed message part
* gnu/packages/patches/imagemagick-CVE-2020-27829.patch: New patch.
* gnu/local.mk (dist_patch_DATA): Register it.
* gnu/packages/imagemagick.scm (imagemagick/fixed): Apply patch to existing
graft.
---
gnu/local.mk | 1 +
gnu/packages/imagemagick.scm
CVE-2020-27829 18:15
A heap based buffer overflow in coders/tiff.c may result in program
crash and denial of service in ImageMagick before 7.0.10-45.
Upstream patch available at
https://github.com/ImageMagick/ImageMagick/commit/6ee5059cd3ac8d82714a1ab1321399b88539abf0
Not yet backported to 6.x
us to put an end
to these problems that affect many new users and remains obscure for
them that they would need to add additional packages in their
configuration (and which).
Léo
signature.asc
Description: This is a digitally signed message part
On Thu, 2021-03-25 at 21:23 -0400, Mark H Weaver wrote:
>
> Just a reminder that, just as with 'mysql/fixed', 'sqlite/fixed'
> should
> *not* use 'package/inherit', since the package you're defining is the
> replacement for the package you're inheriting from.
>
> Otherwise, it looks good to me!
101 - 200 of 1128 matches
Mail list logo
