Re: License of your contributions to the blog at guix.gnu.org

[Léo Le Bouter]

On Sat, 2022-02-05 at 14:47 +0100, Ludovic Courtès wrote:
> Hello,
> 
> I am emailing you on behalf of the GNU Guix project because you are
> the
> author or coauthor of one or more articles to the blog at
> .
> 
> With a few exceptions, these articles do not have a clear license,
> which
> we would like to fix.  We propose to dual-license all the articles
> under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant
> Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
> 
> Do you agree with the proposed licensing terms for your contributions
> to
> the blog?
> 
> If you do, please reply to this message to say so, keeping
> guix-devel@gnu.org Cc’d (if you already replied in the previous
> thread,
> you do not need to reply again).
> 
> If you would prefer different licensing terms, or if you have any
> questions, feel free to ask them publicly on guix-devel@gnu.org or
> privately with guix-maintain...@gnu.org.
> 
> The clarified license will allow us and others to reuse material in
> the
> manual, cookbook, and in other free cultural works.  See
> 
> for the initial discussion.
> 
> Thanks in advance!
> 
> Ludo’.

I agree to dual-license any of my blog posts under CC-BY-SA 4.0 and
GFDL version 1.3 or later, with no Invariant Sections, no Front-Cover
Texts, and no Back-Cover Texts.


signature.asc
Description: This is a digitally signed message part

Re: Leaving the GNU Guix community

[Léo Le Bouter]

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 contributing to GNU Guix anymore in the 
> > future.
> 
> That's a great pity.  I hope to welcome you back some day.  Guix 
> is better off with your fixes.
> 
> Yet I'm convinced that the decision to suspend commit access was 
> the right one.  It wasn't easy.  Nobody was happy about it.
> 
> I also hope that you can accept your role in the events that lead 
> to it and learn from them and make adjustments.
> 
> I'm disappointed that you still deflect the brunt of the 
> responsibility to others and refuse to acknowledge that this, 
> itself, is a problem.  Saving face consistently took precedence 
> over accepting feedback.  That's a dangerous blind spot to have.
> 

I do not think that is true, I think that I do not feel welcome to
acknowledge criticism when it is not written in a friendly manner
(because it generates confrontation), and also I can disagree with
criticism. I think I have acknowledged lots of criticism over the
course of contributing to GNU Guix and this is not taken into account
AT ALL, and that you think that this decision was right I think further
re-inforces that I will not be contributing to GNU Guix in the future.
You failed to recognize the effect of the tone in the messages, and how
deeply it affects me and my ability to feel happy and also to be
constructive (which includes responding in a useful way to criticism).
I don't feel that I can change that. I can only survive in environments
where discussion is exceptionally caring and friendly for this very
reason. I feel deeply affected by everything that's said by people,
even through Internet messages.

I think it is a disaster that you (maintainers) choose to blame someone
publicly for feeling so bad after having received messages of
exceptional aggressivity. I think it is not fair and not justified.
That you insist for me to reply to some aggressive message, I think
that is a disaster. I think it is an horrible thing to ask to someone.

> > I think that the GNU
> > Guix maintainers justify unacceptable behavior and have acted 
> > upon
> > things without understanding them, not understanding why 
> > incidents have
> > happened
> 
> We have a much better understanding of the *complete* situation 
> than you imply.  It's far too common and too convenient to claim 
> that people you don't agree with are (at best) uninformed.

I don't think I am doing any of that and it's hurtful you say I am. I
am not. I really do think that we do not understand each other, on an
emotional level.

> 
> We've certainly made mistakes over the years.  Being buggy humans 
> we'll be sure to make more.
> 
> Several contributors expressed (in at least one case: severe) 
> unease with your attitude long before Mark sent his own unpleasant 
> message, and I think we did too little and waited too long to 
> publicly address either in a coordinated manner.  Lesson 
> hard-learnt.

I think that there's been disagreements and that it's been difficult to
handle for both me and other people. I think people must acknowledge
that I can have my own way of contributing to GNU Guix that can really
make sense and that I am not bound to listen to anyone's criticism if
it doesnt make sense to me and that I cannot or am not willing to do
the work to adapt my contributions to said criticism. If you are
talking about the Zimoun case, as unfortunate as it is that they went
away, I don't think it can be blamed solely on me. They also wanted to
go. What I expressed earlier about their postings remains true for me.
I felt harassed by their postings and that's the reason it also went
off the rails. I think that there's a difference in treatment between
people that contribute to GNU Guix, that not all contributors to GNU
Guix are considered equal, that I have been the subject of criticism
but that some other contributors to GNU Guix will not be the subject of
criticism for various other reasons. I feel like I should be treated
like a person with their own opinions and preferences when it comes to
contributing and that the way I choose to do the contributions as long
as I am the one making them should be respected and that if there's
criticism it is welcome but that if I do not agree with such criticism
that my disagreement be respected. As comparison, I rarely go and
criticize other's work, I trust people to do the best. I know everyone
goes and checks if their own contributions work great from time to
time, but for that to happen you must give the authors that time. I am
able to and I know everyone is able to self-criticize their work and
adapt also. You just have to give trust. I have not heard many people
criticize code quality or anything else when it is maintainers like
Mathieu or Ludovic that broke stuff. I 

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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 which
> > > do
> > > not
> > > meet the project's communication standards, but also by your
> > > apparent
> > > lack of will to reply constructively to legitimate criticism.
> > > 
> > > This is the next in a series of incidents.  The incidents are
> > > okay
> > > --we
> > > we all make mistakes and that's how we learn--but we interpreted
> > > your
> > > responses all too often as dismissive and defensive, rather than
> > > understanding and forward-looking.  This has been causing
> > > unnecessary
> > > friction and stress, and is not how we envision peaceful
> > > collaboration.
> > > 
> > > I'm sorry to say your commit privileges have been temporarily
> > > suspended.  After one month, you are invited to get in touch with
> > > the
> > > maintainers collective and discuss next steps.
> > > 
> > > You have done terrific work in Guix in the short time you've been
> > > around: from the POWER9 port, to the many security fixes,
> > > to tracking and reporting issues, and suggesting improvements to
> > > the
> > > tools.  I hope you'll eventually rejoin to collaborate in the
> > > peaceful
> > > and empathetic fashion that this project encourages.
> > > 
> > 
> > Hello!
> > 
> > To make a statement about this on the public mailing list also, I
> > think
> > such suspension is largely unfair and unjustified.
> I personally disagree.  While their tone may have been questionable,
> I
> find it important that both committers and non-committers are able to
> call changes into question, everything else would not be democratic. 
> Ideally, that would happen during review, but this thread has clearly
> indicated that the review process failed in this instance.  Perhaps
> informing you privately first is more fair, but pointless assignments
> of guilt aside it is an issue that we should all be aware of and
> learn
> from, so as to not repeat it.
> 
> > It seems I am expected to do peaceful collaboration with people who
> > are
> > not writing messages in a non-violent manner, and I refuse to
> > engage
> > further in that context. I do not want to answer Mark or anyone
> > else
> > who does not write in a friendly way. If that means I cannot be a
> > GNU
> > Guix contributor then I will not be any longer. It means for me
> > that
> > GNU Guix is not a safe place for me to contribute to.
> Even if unfriendly, we are not attacking you on any non-technical
> grounds, but instead asking you to do self-criticism and to learn
> from
> your mistake.  You can (and should) call the tone in which this is
> done
> into question, but this does not absolve you from your duty to ensure
> package quality standards.
> 
> > I think if anyone expects me to not answer in a dismissive or
> > defensive
> > way then also they must think of the message they're writing if it
> > is
> > encouraging a confrontational response or peaceful collaboration. I
> > don't feel like I have been hindering peaceful collaboration at any
> > time, since everything I've done in GNU Guix was collaborative
> > work.
> > With many people in the GNU Guix community everything goes well and
> > is
> > very peaceful, when there's problems it's with specific people who
> > also
> > happen to write messages in a way that generates confrontation. I
> > cannot and I refuse to collaborate with people who are not being
> > friendly and do not care about the emotions of the humans they're
> > communicating with, it's the reason I come to GNU Guix in the first
> > place, but to me it appears it's not the right place for that
> > either
> > now.
> The criticisms pointed at you comes not just from Mark, but others as
> well.  Others, who I would argue, potentially phrase them in a less
> confrontational manner.  Leaving them unanswered just because Mark's
> tone was inadequate is in my opinion not justified.
> 
> Regards,
> Leo
> 

Hello Leo,

If the criticism is well phrased in the first place, then I have no
issue to address it and go on constructively. The very problem is that
it wasnt well phrased. The rest cannot work great. I am unable to
collaborate in these conditions, I don't think this can change, I am
not even willing to make such change, that is, to accept collaboration
with people who do not care about communicating in a caring way. I
think it is contradictory to GNU Guix spirit to expect me to do that,
and I cannot emotionally do so, even if I wanted to. I have had too
much suffering due to these situations before, I don't want this to
repeat here and now.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Léo Le Bouter]

On Wed, 2021-04-28 at 12:43 -0400, Mark H Weaver wrote:
> I'm sorry if this comes off as obtuse, but having now re-read all of
> my
> messages in this thread, I honestly do not see what I did wrong here.
> I will need some help to understand.
> 
> With very few exceptions, almost 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, have criticized my "tone".  This is very
> subjective, especially over email where we must *imagine* the tone of
> the speaker.  Is it possible that you read more in my messages than I
> actually wrote?
> 
> It would be very helpful if you could point out specific messages or
> quotes of mine to illustrate your criticisms, and to clearly explain
> what's wrong with them.  I'm not trying to be obstructionist here.  I
> honestly don't understand, and I cannot improve without
> understanding.
> 
>  Thanks,
>Mark
> 

If you really do not understand, I encourage you read 
https://en.wikipedia.org/wiki/Nonviolent_Communication and associated
works.


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[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 which do
> not
> meet the project's communication standards, but also by your apparent
> lack of will to reply constructively to legitimate criticism.
> 
> This is the next in a series of incidents.  The incidents are okay
> --we
> we all make mistakes and that's how we learn--but we interpreted your
> responses all too often as dismissive and defensive, rather than
> understanding and forward-looking.  This has been causing unnecessary
> friction and stress, and is not how we envision peaceful
> collaboration.
> 
> I'm sorry to say your commit privileges have been temporarily
> suspended.  After one month, you are invited to get in touch with the
> maintainers collective and discuss next steps.
> 
> You have done terrific work in Guix in the short time you've been
> around: from the POWER9 port, to the many security fixes,
> to tracking and reporting issues, and suggesting improvements to the
> tools.  I hope you'll eventually rejoin to collaborate in the
> peaceful
> and empathetic fashion that this project encourages.
> 

Hello!

To make a statement about this on the public mailing list also, I think
such suspension is largely unfair and unjustified.

It seems I am expected to do peaceful collaboration with people who are
not writing messages in a non-violent manner, and I refuse to engage
further in that context. I do not want to answer Mark or anyone else
who does not write in a friendly way. If that means I cannot be a GNU
Guix contributor then I will not be any longer. It means for me that
GNU Guix is not a safe place for me to contribute to.

I think if anyone expects me to not answer in a dismissive or defensive
way then also they must think of the message they're writing if it is
encouraging a confrontational response or peaceful collaboration. I
don't feel like I have been hindering peaceful collaboration at any
time, since everything I've done in GNU Guix was collaborative work.
With many people in the GNU Guix community everything goes well and is
very peaceful, when there's problems it's with specific people who also
happen to write messages in a way that generates confrontation. I
cannot and I refuse to collaborate with people who are not being
friendly and do not care about the emotions of the humans they're
communicating with, it's the reason I come to GNU Guix in the first
place, but to me it appears it's not the right place for that either
now.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

On Fri, 2021-04-23 at 15:18 -0400, Leo Famulari wrote:
> I have to agree with everybody in this thead.
> 
> The commits in question were problematic (especially on core-updates,
> which is not a "WIP" branch and thus cannot be rewritten to fix past
> problems). I'm not confident 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 version in a different commit. `git rebase` is the
> tool to learn for cases like this one.

I do not think here that Raghav and myself should somehow be framed as
people having to learn more and that would be the reason for these
issues. To talk about myself, I think the main difference here is that
Mark and myself consider different things to have value when
contributing to GNU Guix. Mark tends to consider the technicality of
contributing to GNU Guix, that the code be well tested, that every
change be made in a very rigorous way. I tend to also consider these
things but also consider other things like how people feel when they
contribute to GNU Guix, do they feel discouraged or rewarded by their
contributions, I find that it can be tiring and very discouraging to
respond back and forth to many many review comments, and at some point,
even if things have some rough edges, I tend to prefer rewarding a
contributor for their work than insist the commit history should be
perfect or something. I also stopped upholding myself to high rigorous
standards at all times, also because I think it is not good for my
mental health. I tend to move the responsability of rigorous testing
into tools, I think putting testing/checking into tools is at the same
time good for mental health and inclusive because it means also
everyone can check their own changes and correct errors. Having tools
to check things is less stressful for everyone, I discovered that
aspect after I learned Rust and I think it really is the way to go. I
think there is an aspect of contribution where people feel stressed and
doubt themselves and that's what keeps them away from contribution, if
we have tools then those problems tend to disappear because the tool
acts as a stopgap, the tool can also be collectively improved as soon
as more best practices are discovered by the community. Rust does this
with clippy lint rules, the borrow checker and the very well made
error/warning reporting of the compiler. I think relying more on tools
even if we never can do so fully and less on individual accountability
is better here.

> 
> However, Mark, you have way more experience, and you need to handle
> these things differently. If you don't trust certain Guix
> contributors,
> take it up with the maintainers — in private. The style of
> communication
> you used here is ineffective and will dissuade people from
> contributing
> to Guix. Do you want Léo and Raghav to learn and improve? Or do you
> want
> them to leave? Remember that we all begin as beginners.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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 please explain what went wrong here?
> 
> Is a reasonable question, shared by all of us, not just Mark.  The 
> constructive way forward is to answer it fully.  It's in your best 
> interest to do so.
> 
> Kind regards,
> 
> T G-R

I am sorry, I will not. It's evident nothing went wrong and Mark is not
asking questions that are beneficial to anyone here besides
contributing to public shaming of people. The fix is already pushed and
thank you to the person that made it and Mark for identifying the
issue, however I don't say thank you for trying to publicly shame
people on the mailing list, both Raghav and me. At best there was an
oversight (like there's many in various commits made everyday to GNU
Guix) where I assumed the latest version of software would contain all
security fixes (as I tend to consider GNONE software such as cairo is
well maintained upstream security-wise, seems not), I don't think
there's anything more to add. I find Mark's way of communicating about
these issues not constructive and unfriendly. I think that if Mark or
anyone else's expect me to answer I think they should not phrase
criticism in a way that they accuse me or anyone else of having made a
mistake. I don't think we should find who is responsible for mistakes,
we could however ask advice on what happened to fix the mistake in case
the person that introduced it cannot. And to ever think I would act in
bad faith towards GNU Guix security when I spent entire weeks checking
and patching CVEs full time, I don't think that would make sense.

On Mon, 2021-04-26 at 19:21 +0200, Ludovic Courtès wrote:
> Hi Léo,
> 
> Tobias Geerinckx-Rice  skribis:
> 
> > > 
https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
> > > 
https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> > > Can you please explain what went wrong here?
> > 
> > Is a reasonable question, shared by all of us, not just Mark.  The
> > constructive way forward is to answer it fully.  It's in your best 
> > interest to do so.
> 
> I concur.  Please reply as soon as you can so we can understand what
> happened, restore trust, and collectively avoid such pitfalls in the
> future.
> 
> Thanks in advance,
> Ludo’.

I don't understand how trust would be lost.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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 not okay to remove security patches and
> > > later
> > > update a package to a fixed version in a different commit. `git
> > > rebase` is the tool to learn for cases like this one.
> > 
> > I knew about this but I didnt feel like telling Raghav to do yet
> > another rebase. I felt like Raghav was taking on with so much
> > already.
> 
> This response is what native English speakers call a "red herring"
> <https://en.wikipedia.org/wiki/Red_herring>;: something that misleads
> or
> distracts from a relevant or important question.
> 
> Why do I say that?  As I pointed out elsewhere in this thread,
> 
>   https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00366.html
> 
> it appears that Raghav didn't actually remove the security fixes; it
> appears that *you* did.  Therefore, I fail to see how it could have
> been
> avoided by asking Raghav to do another rebase.
> 
> From the IRC logs cited in the message above, it appears that you
> took
> the liberty of modifying Raghav's "cosmetic changes" commits to also
> remove security fixes in the re-indented packages, while claiming in
> the
> summary lines that you were "ungraft[ing]" cairo and glib.
> 
>   
> https://git.sr.ht/~lle-bout/guix/commit/a045a48dd961f0c5c3d536dcc3fd21d9c08d2d50
>   
> https://git.sr.ht/~lle-bout/guix/commit/6477daa338fbf1c9edacfc3690aca77cacfe0008
> 
> Can you please explain what went wrong here?
> 
>   Thanks,
> Mark
> 

Hello Mark,

I will not answer anything to you anymore because I feel like you do
not write messages in a constructive way.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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
> tool to learn for cases like this one.

I knew about this but I didnt feel like telling Raghav to do yet
another rebase. I felt like Raghav was taking on with so much already.
The rebase was specially complicated because Raghav's commit changed
indentation, git has bad quite bad UX for cases like these. At the time
I had lots of things to handle also and couldnt spend lots of time on
it myself. I didnt feel like blocking the merge of these patches for
commit history was worth it at all. Such blocking could have hindered
the GNOME upgrade effort even more. Thankfully now there's lots of
energy being put to it, at the time there wasnt anyone else than Raghav
and me.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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 you had planned to do this update, but it
> somehow
> fell into the cracks?  In any case I agree with the others that it'd
> have been better to ungraft/remove patches in the same commit that
> updates the software to a version that incorporates the fixes, as I'm
> sure you already know: it'd have prevented this kind of situation.

Considering the GNOME upgrade is not finished yet, this is indeed
ongoing work. I would've never done this on master.

> 
> I also urge you to remain calm and collaborative even in the face of
> criticism; as Ricardo said, escalating things will lead us nowhere
> good.
> Honest mistakes are made and that's no problem so long as we stand
> ready
> to apologize for them and work together for a resolution.
> 

I think there is no problem in accepting criticism but there is a
certain way Mark presents criticism and I don't feel like I can respond
to it when it is written in such way. Over several emails Mark was
looking to point to people who were somehow responsible for whatever
"damage" for changes that happened on a branch nobody uses and always
contains ongoing work (core-updates), so maintaining it security-wise
is not as much of a question. The result is that we have a long thread
of people responding etc. causing a fuss over something that just needs
to be fixed rather than find whoever is somehow "responsible". I feel
like we're collectively responsible. We try our best at all times,
during this GNOME upgrade I also tried to take into account Raghav's
feelings so they do not give up and have a rewarding review experience,
I knew these commits werent great, I have written about it here: <
https://issues.guix.gnu.org/42958#67>.

> I see that 宋文武 has pushed a commit
> (2ab4f4c950ffa7ca40271a534cb3bed997672138) to core-updates
> reinstating
> the security patches; thanks!
> 

Great! Thanks for figuring this out.

> Thank you,
> 
> Maxim
> 
> [0]  https://www.cairographics.org/releases/
> [1]  
> https://nvd.nist.gov/vuln/search/results?form_type=Advanced_type=overview_type=all=cpe:2.3:a:cairographics:cairo:-:*:*:*:*:*:*:*

Léo


signature.asc
Description: This is a digitally signed message part

Re: Another misleading commit log (was Re: A "cosmetic changes" commit that removes security fixes)

[Léo Le Bouter]

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 more focused and spend more time sending accusations
here than collaboratively working to improve GNU Guix. I don't feel
like that's something great to do at all.

Léo


signature.asc
Description: This is a digitally signed message part

Re: A "cosmetic changes" commit that removes security fixes

[Léo Le Bouter]

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
> > > fixes, and yet the summary lines indicate that only "cosmetic
> > > changes"
> > > were made.
> > 
> > Yeah, the commit title didn't mention the change but the commit
> > message did.
> 
> I'm sorry, but that won't do.  There are at least three things wrong
> with these commits:
> 
> (1) The summary lines were misleading, because they implied that no
> functional changes were made.
> 
> (2) The commit messages were misleading, because they failed to
> mention
> that security holes which had previously been fixed were now
> being
> re-introduced.  That wasn't at all obvious.
> 
> Commits like these, which remove patches that had fixed security
> flaws, are fairly common: someone casually looking over the
> commit
> log might assume that the patches could be safely removed because
> a
> version update was done at the same time, rendering those patches
> obsolete.
> 
> (3) Although your 'glib' commit was immediately followed by a 'glib'
> update, rendering it harmless, your misleading 'cairo' commit
> left
> 'cairo' vulnerable to CVE-2018-19876 and CVE-2020-35492 on our
> 'core-updates' and 'wip-gnome' branches.  Those will need to be
> fixed now.
> 
> Léo Le Bouter  is also culpable here, because he
> digitally signed the misleading 'cairo' commit that's on our
> 'core-updates' branch, which re-introduced CVE-2018-19876 and
> CVE-2020-35492.
> 
> --8<---cut here---start->8---
> commit f94cdc86f644984ca83164d40b17e7eed6e22091
> gpg: Signature made Fri 26 Mar 2021 05:13:57 PM EDT
> gpg:using RSA key
> 148BCB8BD80BFB16B1DE0E9145A8B1E86BCD10A6
> gpg: Good signature from "Léo Le Bouter "
> [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to
> the owner.
> Primary key fingerprint: 148B CB8B D80B FB16 B1DE  0E91 45A8 B1E8
> 6BCD 10A6
> Author: Raghav Gururajan 
> Date:   Fri Dec 4 00:48:43 2020 -0500
> 
> gnu: cairo: Make some cosmetic changes.
> 
> * gnu/packages/patches/cairo-CVE-2018-19876.patch,
> gnu/packages/patches/cairo-CVE-2020-35492.patch: Remove patches.
> * gnu/local.mk (dist_patch_DATA): Unregister them.
> * gnu/packages/gtk.scm (cairo): Make some cosmetic changes.
> [replacement]: Remove.
> (cairo/fixed): Remove.
> 
> Signed-off-by: Léo Le Bouter 
> --8<---cut here---end--->8---
> 
> https://git.sv.gnu.org/cgit/guix.git/commit/?h=core-updates=f94cdc86f644984ca83164d40b17e7eed6e22091
> 
> Even the most superficial skimming of this commit should have
> immediately raised red flags, because the summary line is clearly
> inaccurate.  It shows a lack of careful review, to put it mildly.
> 
>   Mark

Hello Mark,

I don't share your analysis, the security fixes werent stripped because
glib/cairo was also updated to latest version in subsequent commits
which were pushed all at once.

Careful review was done, and that's why I signed-off and GPG-signed the
commits. Nobody was put at risk by these commits and no security fixes
were stripped.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Please review blog post draft: powerpc64le-linux support

[Léo Le Bouter]

On Mon, 2021-04-12 at 12:46 -0700, Chris Marusich wrote:
> Hi,
> 
> Chris Marusich  writes:
> 
> > This is the final draft, I think.  I intend to commit it to the
> > "posts"
> > directory in guix-artwork on Monday morning, USA time, at which
> > point 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 they either didnt take it into account or didnt see it for now.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Please help reviewing CVE entries

[Léo Le Bouter]

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
> > feeling
> > held back because I abandonned the CVE entries reviewing task
> > without
> > anyone doing it when I'm not here.
> 
> Thanks for your work
> > Right now at time of sending this email, I've reviewed in-order up
> > until CVE-2021-26709 on the 
> > https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml feed, I use the
> > 'quiterss' package as an rss reader.
> > 
> I just subscribed to the feed, and noticed our version of dnsmasq
> might
> be vulnerable to CVE-2021-3448, I'll follow your suggestions here and
> open a bug report.
> 
> Thanks, Nicolò

That's one really good review you opened at bug#47674

Thank you so much!!

Keep it up!



signature.asc
Description: This is a digitally signed message part

Please help reviewing CVE entries

[Léo Le Bouter]

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, I've reviewed in-order up
until CVE-2021-26709 on the 
https://nvd.nist.gov/feeds/xml/cve/misc/nvd-rss.xml feed, I use the
'quiterss' package as an rss reader.

I need help, it's not necessarily a very hard task for most of it, but
it's one that requires you to be here often to read the feed.

Once I see a CVE entry, for example:

CVE-2021-30177  07.04.21 13:15
There is a SQL Injection vulnerability in PHP-Nuke 8.3.3 in the User
Registration section, leading to remote code execution. This occurs
because the U.S. state is not validated to be two letters, and the
OrderBy field is not validated to be one of LASTNAME, CITY, or STATE.

I look at the summary, here "PHP-Nuke" seems to be the software name, I
know that the PHP eco-system is not very advanced with GNU Guix
packaging so I suspect it might not be packaged since not a lot of PHP
packages exist.

I run these commands to find out:

$ guix search php-nuke
$ guix search php nuke

No results, then some times GNU Guix names packages with the name of
the upstream repo rather and sometimes that's different, so I look into
the URL for the CVE entry:

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-30177

Section: References to Advisories, Solutions, and Tools

Often the upstream repo URL is there with a commit or some times an
issue URL where we can find the upstream repo URL, in this case there's
just a PoC link:

https://gist.github.com/stacksmasher007/41e946fc9a5a2f0b6950626cc9d43d47

So after that, to make sure, I do a last try with a web search for
'PHP-Nuke' here we can find the upstream repo:

https://bitbucket.org/phpnuke/phpnuke

Then:

$ guix search phpnuke

Still no results, so we are pretty confident this doesnt exist in GNU
Guix and we can go to the next entry.

Probably there's no need to be as rigorous and precise as this for
every CVE entry, apply your best gut to it.

Then if you find a GNU Guix package for a CVE entry, look at the
version, figure out from available information if that version is
vulnerable, if it's vulnerable and you are certain, open a bug by
sending an email to bug-g...@gnu.org similar to these for example: 
https://issues.guix.gnu.org/47422 - try to include in the bug how to
fix the issue, by saying which version fixes it, or link to individual
patches or commits that can be applied (and backported if necessary) to
fix the issue.

Then once you sent the email and got the bug id, send an email like
this to cont...@debbugs.gnu.org to add the 'security' tag:

tags 47422 + security
quit

Replace 47422 with the bug id you got.

If you are not certain the version is vulnerable, then you can use 'may
be vulnerable' in the title and include all the details you've got so
others can pick it up, or even yourself later, so no information is
forgotten, similar to this https://issues.guix.gnu.org/47509 ; We
really don't want to forget patching a CVE.

You can find examples of existing bugs tagged for security with:

https://issues.guix.gnu.org/search?query=tag%3Asecurity

Also opened bugs tagged for security (definitely help tackle those as
well):

https://issues.guix.gnu.org/search?query=tag%3Asecurity+is%3Aopen

My security bugs I opened you can also take example from:

https://issues.guix.gnu.org/search?query=tag%3Asecurity+submitter%3Alle-bout

Then as for patching the actual issue in the GNU Guix package set, you
must first find the amount of dependents that package has using 'guix
refresh -l pkg_name', if it's larger than 300 then you will need to
graft to fix the security issue, otherwise you can just update the
package.

For grafts, you either have to use ABI compatible replacements like in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=f4dc8ac6dfa036d98aa0990ae22268a9650899d0
 or you must apply/backport patches to the version currently packaged
in GNU Guix like in 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=52c8d07a4f7033534a71ac7efeec21a65d35c125

If you feel like you will get things wrong when backporting some patch
because you don't know the language enough or else then ask for help
and people will help with backporting ASAP. If backporting is too hard
and nobody can do it but fixing that particular security issue is
important because of the severity, then we have to negotiate cutting
corners with the rest of the GNU Guix community, for example recently
syncthing package: https://issues.guix.gnu.org/47627 - upgrade was
blocked because unvendoring was difficult on newer versions, seeing a
CVE it can be considered acceptable to not unvendor and leave things
vendored and build as-is until we can unvendor/unbundle properly later.

If the package has less than 300 dependents then you can just upgrade
that 

Re: Semi-automated patch review

[Léo Le Bouter]

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 people to unsubscribe considering the already
existing flood of information in the guix-patches list.


signature.asc
Description: This is a digitally signed message part

Re: Please review blog post draft: powerpc64le-linux support

[Léo Le Bouter]

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 available right now."
> 

I've been using the Free Software firmware replacement for the NIC
since a while now and it's working great: 
https://github.com/meklort/bcm5719-fw/


signature.asc
Description: This is a digitally signed message part

Re: Please review blog post draft: powerpc64le-linux support

[Léo Le Bouter]

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-linux support and explain why it matters (POWER9 is an
> exciting, freedom-friendly platform!).  The secondary goal is to
> explain
> some of the details about what we did, and invite people to get
> involved.
> 
> Your feedback would be highly appreciated!
> 

It's been mostly you here Chris, thank you so much for writing it, as
others said, it is really beautifully written! Unfortunately I havent
felt enough peace of mind to write like you did :-(

I would've liked to write about the early days where I met some
problems with the core-updates branch having to rebase several times
and learning GNU Guix at the same time since my first ever project
related to GNU Guix was porting before even trying to use it elsewhere.
Having to learn the GNU commit message guidelines, then learning git-
send-email and GNU Emacs (since that's where all dev tools are), all
that to contribute to GNU Guix and get this port in. Aaaahh very long
story!

Léo


signature.asc
Description: This is a digitally signed message part

Re: guix home: Call for Early Adopters

[Léo Le Bouter]

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 Guix),
> who want to try `guix home` and are willing to spend some time and
> effort configuring it, and in case of issues reporting them to
> https://lists.sr.ht/~abcdw/rde-discuss
> 
> We will be supporting early adopters in the rde-discuss mailing list
> on
> weekdays.  Also, you can reach us on #guix IRC channel for a casual
> talk
> or quick question, @abcdw and @yoctocell.
> 
> On `date --date="2021-04-14 15:00:00 UTC"` we plan a jitsi call, to
> make sure that everyone is up and running, provide some help and/or
> answer questions.  Will schedule consequent calls if needed.
> 
> To participate you need to have a working installation of Guix the
> package manager, and have a local checkout of the rde Git
> repository[1].  Reply to the thread in rde-discuss [2] with a few
> lines about you and/or your technical background and please attach
> the
> output of running `make env-info` at the root of the rde repository
> to
> be sure that Guix and rde are installed and everything works
> correctly.
> 
> See you soon,
> Andrew Tropin.
> 
> Useful links:
> [1] https://git.sr.ht/~abcdw/rde
> [2] https://lists.sr.ht/~abcdw/rde-discuss
> 

Really Awesome :-)

Could you sign your rde channel? I am not at ease adding unsigned
channels since that's basically RCE into my system :-)

Thanks!!


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

On Wed, 2021-03-31 at 14:16 -0400, Leo Famulari wrote:
> 
> Yeah, I agree that it's hard to learn about "what's cooking" when you
> first arrive at the mailing lists.
> 
> It's true that wikis tend to get out of date, but I think that it
> won't
> be too bad for this use case. At least, it won't be worse than the
> mailing lists, for newcomers who want to know about longer-term
> efforts
> like the GNOME upgrade.

I am thinking we could establish policy so that the WIP wiki page is an
index to mailing list threads, git branches or other "updatable"
locations so that it is less likely to need updating and therefore
stays updated w.r.t. it's main purpose: finding out about WIP work.

The policy would say that one must create a mailing list thread, git
branch or else and link it there and **NOT** include original
information on the wiki page 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

Semi-automated patch review

[Léo Le Bouter]

Hello!

Cbaines already runs automated patch testing infra at 
https://data.guix-patches.cbaines.net/ and 
https://patches.guix-patches.cbaines.net/project/guix-patches/list/

Considering that posting robot messages with test/lint/+ result
information on the issues directly and on the ML might get spammy, I
suggest that Cbaines could setup something that sends off-list to all
the participants or just the poster of the patch being tested, as well
as another list like guix-ci-...@cbaines.net that reviewers could
voluntarily subscribe to to receive all those off-list messages.

Another suggestion is that the infrastructure by Cbaines could include
an easy way to lookup CI information from a bug id and that a link to
see such CI information could be linked to from Mumi's
(issues.gnu.guix.org) UI. But I also really think that mailing the
contributors privately is very important so they can get automated
feedback and save us time without any additional setup or knowledge
required.

What do you think?

I think it's really important that we move forward on this topic where
honestly lots of things have been achieved especially by Cbaines but
with poor visibility so no actual usage to aid the review process when
we would crucially need such help.

Thank you!

Léo


signature.asc
Description: This is a digitally signed message part

Re: Secure GNU Guix offloading

[Léo Le Bouter]

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
> > Guix offloading so it can work even without the offload machine
> > trusting the client's store public signing key.
> 
> One possibility would be to give SSH access and nothing more.  That
> would allow hackers to run:
> 
>   GUIX_DAEMON_SOCKET=ssh://leo.example.org guix build whatever
> 
> Users would still be able to retrieve build results from your machine
> via ‘guix copy’ or an instance of ‘guix publish’ running on the
> machine.
> 
> HTH!
> 
> Ludo’.

Thank you! I did not know setting daemon address over SSH was possible!


signature.asc
Description: This is a digitally signed message part

Re: Rust and parametric packages

[Léo Le Bouter]

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
> 
> Access requires a login. Is there a publicly available mirror?
> 

Unfortunately I don't think so!


signature.asc
Description: This is a digitally signed message part

Re: Security related tooling project

[Léo Le Bouter]

On Sat, 2021-04-03 at 11:41 +0100, Christopher Baines wrote:
> Hey,
> 
> In May last year (2020), I submitted an application to NLNet. The
> work I
> set out wasn't something I was doing at the time, but something I
> hadn't
> yet found time to work on, tooling specifically around security
> issues.
> 
> The application got a bit lost, probably somewhat down to email
> issues
> on my end. Anyway, things picked up again in February of this year
> (2021), and this is now something I'm looking to do roughly over the
> next 8 months.
> 
> I've been working on stuff in and around Guix for I think around 5
> years
> now, and in that time I have attempted some big projects,
> particularly
> things like the Guix Data Service and Guix Build Coordinator. I've
> fit
> all of that around a regular non-Guix related work. The support of
> NLNet
> means I'm able to set aside more time for Guix and this work, exactly
> how much more time I can dedicate is something I'm still working on.
> 
> There's a more complete description of the aims and tasks here [1],
> this
> email is effectively the start of the work. I want to get lots of
> input
> and feedback on the plans I've set out, as well as checking if
> there's
> any related or overlapping work going on.
> 
> 1: 
> https://git.cbaines.net/guix/tooling-to-improve-security-and-trust/about/
> 
> I'm particularly excited by some of the initial work. I'm hoping
> getting
> some initial version of Guix Data Service subscriptions in place will
> open up loads of opportunities, and getting data about package
> replacements (grafts) in to the Guix Data Service will be generally
> helpful as well.
> 
> Once that's in place, I want to tackle 3 areas: security issues from
> a
> project perspective, security issues from a individual user
> perspective
> and prototype some enhancements to the patch review process,
> specifically around security.
> 
> In terms of looking at security from a project perspective, I'm
> thinking
> about these kinds of needs/questions:
> 
>  - What security issues affect this revision of Guix? (latest or
> otherwise)
> 
>  - How do Guix contributors find out about new security issues that
>affect Guix revisions they're interested in?
> 
> From the user perspective, I want to look at things like:
> 
>  - How do I find out what (if any) security issues affect the
> software
>I'm currently running (through Guix)?
> 
>  - How can I get notified when a new security issue affects the
> software
>I'm currently running (through Guix)?
> 
> Please let me know if you have any comments or questions!
> 
> Thanks,
> 
> Chris

That's really really awesome Chris! I especially like that also users
are invited to particpate in the process and the information is shared
there 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

Re: Application for aarch64 computing resources

[Léo Le Bouter]

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, "Any customer can have a car
> painted any color that he wants so long as it is black." 
> 

If we have an entire Ampere Altra to build our stuff, holy we will have
so much compute power. Probably it's the fastest single machine on
earth right now. 


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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
> • Videos
> • Cookbook
> • GNU Manuals
> • Wiki
> • IRC Chat
> • Mailing lists
> 
> If people think it's ok.

Thanks a lot for the patch Luis! I am really happy it was merged now!


signature.asc
Description: This is a digitally signed message part

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

Sorry for duplicated email,

On Thu, 2021-04-01 at 16:58 +0200, Ricardo Wurmus wrote:
> I don’t think we should have a security-updates
> branch, because the role of that branch is effectively taken by
> staging.

I don't think that's the case because staging is documented for things
that do not make too many rebuilds (in which case they'd go to core-
updates), and some times security updates do cause rebuilds in the
1800+ and they could not go through staging. The proposed security-
updates branch would not have that limitation. We could of course also
revisit the policy for 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

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

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 *have* to accept other people’s criticism.  But
> we
> collectively aim to act in a collegial fashion, finding consensus
> before
> forging ahead with changes to processes.  I have not been convinced
> by
> your arguments and your appeals in this discussion.  I can’t speak
> for
> others, but I would consider it very unwise to ignore the lack of
> consensus and just start a new branch when that isn’t what the
> collective of long-term contributors agrees to do. 
> 
> If that’s not what you’re planning to do then my comments carry no
> weight.  I do want to stress, though, that hurry is usually misplaced
> in
> the decision-making process of this project.  There are only few
> exceptions to this and none warrant precipitating a falling-out.
> 

I never planned to go on and create that security-updates branch, it is
clear that there's no consensus for that, also it would require other
tools we don't have. However what I disagree with Simon is that they
think security updates should not be prioritized, which I don't agree
with very strongly. They have repeated that many times in various ways
and it annoys me that these arguments come up again and again in
response to my messages or contributions even though Simon knows I
disagree. There's no other problem to me.

There's a thing about my personality and I am sorry to be that way,
it's that I am ready to question myself but at a point when the demand
to question becomes confrontational way rather than in a friendly way I
stop being able to. I feel like I have taken into account many
criticism and changed my workflow due to that. I am glad people help me
improve the contributions I make to GNU Guix.

This thread is a proposal, like all others were, and on some comments I
feel attacked personally for even mentionning things that are only
proposals to me (I don't even think they're good solutions in the
absolute sense, I just propose them).

Léo


signature.asc
Description: This is a digitally signed message part

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

Hello Ludo,

On Wed, 2021-03-31 at 23:29 +0200, Ludovic Courtès wrote:
> It’s unacceptable to call someone “obsessed” just because you
> disagree
> and calling Simon’s comments “harassment” is equally inappropriate.

I really do feel harassed by their comments, it's not just because I
disagree, it's that I feel they have been following me around in
several of my contributions repeating the same issues, I have heard
their criticism and I do disagree but I don't feel like bringing it up
over and over and over following me around is a great thing to do at
all!

I did not try to go and yell all around after for example 'guix pull'
was broken after some changes to substitutes handling that were pushed
for example. I just trust people to do the best. I know people want the
best for GNU Guix. I also want the best for GNU Guix. I am not trying
to somehow deliberately break GNU Guix.

> We’re all passionate about the project, and each one of us looks at
> it
> from a different angle.
> 
> You’re new to the project.  I think we’re all glad you joined; that
> has
> already boosted security work and the POWER9 port.  But we also have
> expectations: that you follow written rules (the code of conduct, the
> “Commit Access” section of the manual), and the unwritten rule that,
> as
> a newcomer, you would humbly listen to suggestions made by more
> experienced contributors.

I try to listen, and I think I have listened to criticism from many
different people. I think we've reached a point where I could not
listen anymore from Zimoun because I felt we were going in circles.
There's different opinions from different places it seems, where some
people agree with my way of doing and some others do not, and I felt
like I had more approval from other people and that while Zimoun's
criticism has been heard I have not acted upon all of their criticism.
Is it possible to do that?

> The unresolved issues Simon points out are not just technical
> problems;
> they’re a hindrance to our cooperation and to our well-being as a
> group.
> It’s completely okay to make mistakes, but it’s not okay to break the
> community rules and to dismiss the opinion of others as unimportant.

I do not dismiss other's opinion as not important, I disagree, what do
you want me to do? We have different way of doing things, if I do them 
I 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

Re: Document our WIP

[Léo Le Bouter]

On Tue, 2021-03-30 at 12:37 +0200, Ludovic Courtès wrote:
> To me, a good way to make sure work remains “in progress” is to post
> regular updates to this list, and then to write blog posts for the
> web
> site whenever an important milestone is reached.
> 
> I think a web page is likely to quickly become outdated… unless said
> work transitions from “in progress” to “stalled”.  :-)

I feel like using the mailing list fails at solving one concern that is
discoverability of WIP problems for people to show up and help tackle
them, even if they were abandonned by the people 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, that,
for sure.

Léo


signature.asc
Description: This is a digitally signed message part

Re: GNOME 40 work should be done on Savannah

[Léo Le Bouter]

On Tue, 2021-03-30 at 21:55 -0400, Mark H Weaver wrote:
> I'm sorry if that happened.  It was not my intent.  Can you show me
> what
> I wrote that misrepresents your position?

I don't have the energy now I feel already bad enough this discussion
even happened, in a way that even Ludo, the creator of the GNU Guix
project, ended up saying that they think I don't understand the review
process. I think I do understand it and I wonder why anyone made me a
GNU Guix committer if they think any other way.

> I answered essentially the same question in my last message, so I'm
> not
> sure why you're asking again.  We've been successfully accepting
> contributions from non-committers for years.

I think one has to realize that being a non-committer is a really
frustrating experience even if your work is of good quality and that
frustrating experience is demotivating and makes people give up. And
having a branch and special relationship with a GNU Guix committer
(like what we're doing with Raghav) is helpful to capture Raghav's
motivation and energy in a way they do not get frustrated and give up.

> Yes, of course.  To be clear: you are well within your *rights* to do
> so, regardless of what anyone else thinks.
> 
> My main concerns are:
> 
> (1) The primary branch for GNOME 40 work should be on Savannah, and
> that's where we should encourage Guix developers to do this work.
> No Guix developer should be asked to work on an external site in
> order to contribute to the GNOME 40 effort.

That's where it felt it was the best place to collaborate for me and
Raghav (non-committer).

> 
> (2) Any work that you and Raghav do on an external site should be
> _regularly_ merged into Savannah, in manageable pieces, after
> being
> reviewed of course.  If you do this, my concerns over review
> quality
> would be addressed.

We already seek to do this.

> 
> (3) If changes are made on the 'wip' branch on Savannah that conflict
> with your preliminary work on an external site, it would be your
> responsibility to rebase your work as needed, just as anyone
> proposing a patch would be expected to do.  That should be an
> incentive to submit your work to Savannah early and often.

If changes were to be made in a way that rebasing work and solving
conflicts 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

Re: GNOME 40 work should be done on Savannah

[Léo Le Bouter]

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote:
> > I don't feel like people should be barred to contribute to that
> > GNOME
> > 40 upgrade because they arent an approved committer. That doesnt
> > feel
> > inclusive to me.
> 
> I respectfully think you misunderstand the review process.  Review is
> about sharing responsibilities and reducing the likelihood of
> mistakes.

Additionally, please put that quote into it's surrounding context and
don't assume things I have not said, I was explicitly speaking about
wip branches on Savannah excluding non-committers from collaborating on
them easily.

If I created a wip-gnome-40 branch on Savannah then Raghav cannot push
and we cannot work together easily, that way the GNOME 40 upgrade
probably wont happen because Raghav is already tired I felt in some
way.

I think the way we work here is the best conditions to capture Raghav's
motivation and energy right now and invest it within this GNOME 40
upgrade before they give up and we don't have this GNOME 40 upgrade
worked on. We need git to collaborate on patches together, that's all. 
But those patches of course do get through the review 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

Re: GNOME 40 work should be done on Savannah

[Léo Le Bouter]

On Tue, 2021-03-30 at 14:12 +0200, Ludovic Courtès wrote:
> I respectfully think you misunderstand the review process.  Review is
> about sharing responsibilities and reducing the likelihood of
> mistakes.
> 
> It’s crucial from many different perspectives: security-wise,
> socially
> (the process is transparent, everyone gets a chance to chime in or to
> just see what’s cooking), and technically (we all learn and build
> better
> software, and we reduce the risk that users receive broken software
> on
> their next ‘guix pull’).
> 
> The process to get commit access is documented and it revolves around
> two criteria: the person must have experience with the project and
> must
> know the rules.
> 
> That’s not “bureaucracy”: it’s about building a community around
> mutual
> understanding of what each one of us may or may not expect from their
> peers.
> 
> 
> All that said, it’s of course fine to collaborate on external
> repositories, even though I agree with Mark that getting “closer” to
> Guix folks may be profitable to everyone.  In the end, work should be
> submitted for review, and for a patch set like this, it’ll probably
> be a
> ‘wip-’ branch on Savannah.
> 
> Thanks,
> Ludo’.

I think Mark misrepresents my sayings in their messages. We are ONLY
using git to exchange work and collaborate on the patchset with Raghav,
how else do you want us to work with Raghav on some git branch on
Savannah if Raghav doesnt have commit access? Don't we have the right
with Raghav to cooperate together on some patchset however we want? It
never meant that review process had to be skipped in ANY way.

Only Raghav and myself has showed up to cooperate on GNOME 40 upgrade
for now, and 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

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

On Tue, 2021-03-30 at 13:48 +0200, zimoun wrote:
> Ahah, I am happy to know it.  I hope it is because a
> “miscommunication»
> and not because you do not carefully read or because maybe you only
> see
> through the tiny lens of known security vulnerabilities.  From my
> opinion, your point of view to tackle the issue is wrong.  That’s
> said.

I feel harassed by your comments because you obsessed on this zstd
issue and try to make it the cause of some other problems you saw
without any evidence.

I don't think I look through the "tiny lens of known security
vulnerabilities", 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.

> 
> Best regards,
> simon

Léo


signature.asc
Description: This is a digitally signed message part

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Léo Le Bouter]

On Tue, 2021-03-30 at 02:41 -0400, Mark H Weaver wrote:
> Sorry, but that's simply false.  You _do_ have a choice.  You can do
> what we've been doing in the Guix community for years: as a
> committer,
> _you_ can commit the work of non-committers on their behalf.  If not
> you, then any of the other ~64 Guix committers can do so.
> 
> Needless to say, before committing, you must review the proposed
> patches, for the sake of your reputation.  The fact that you must do
> this is a *feature*, not a bug.

Nobody is talking about skipping the review process, as I said, it's
just about collaborating over git rather than with patches (good for
little patches but very troublesome for larger patchsets)

> No one is "barred" from contributing.  Raghav and many others without
> commit access have been successfully contributing to Guix for years.
> 
> I understand that it's inconvenient.  Naturally, you would like to
> eliminate that inconvenience.
> 
> The thing is, the work of non-committers *must* be reviewed at some
> point, anyway.  Moreover, a committer must take responsibility by
> digitally signing it.  To eliminate either of these steps would put
> us
> at risk.
> 
> There's no guarantee that the work of Guix committers will be
> reviewed
> by anyone else, because no one else's reputation is on the
> line.  Some
> of us try to keep an eye on things, but I would not bet on that
> oversight being comprehensive.  I'm certainly not doing it
> comprehensively.
> 
> With this in mind, I think that we *should* have a high standard for
> committers.  The security of our systems, as well as Guix's
> reputation
> as a project, depends upon the good judgment of _every_ Guix
> committer.
> 
> Observe what can happen with projects that are too lax:
> 
>   
> https://arstechnica.com/gadgets/2021/03/buffer-overruns-license-violations-and-bad-code-freebsd-13s-close-call/
> 

I don't think we are on the same page.

> Upgrading GNOME is not trivial.  It will be a large patch set.  A
> large
> patch set presented to guix-patches when the branch is ready to merge
> is
> far less likely to get careful review than if the review is done a
> few
> commits at a time.  That's because, at any given time, it's easier to
> find Guix developers with a few minutes available to carefully review
> a
> small handful of commits, than to find developers prepared to review
> a
> non-trivial branch merge.  If they're reviewed at all, reviews of
> larger
> code drops are more likely to be superficial.

We also go by steps and review things as they appear with Raghav,
collaborating over git is just easier than exchanging patches for
testing/review back

> * * *
> 
> In summary: it seems to me that working in an external repository
> with a
> larger set of committers would not actually save time, 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 vector is just a way to collaborate more easily but
things would still get reviewed (in smaller patchsets if necessary
also) before getting merged.

> Regards,
>   Mark

Léo


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

For reference, crossposting:

I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your
patch. Thank you for it. Let's watch for upstream zstd fix also.

I pushed 9feef62b73e284e106717a386624d6da90750a3d to master.

Ubuntu released a patch in the mean time, so while we couldnt make 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 message part

Re: GNOME 40 work should be done on Savannah (was: Re: GNOME 40)

[Léo Le Bouter]

Hello!

On Mon, 2021-03-29 at 19:02 -0400, Mark H Weaver wrote:
> This sounds theoretical.  Concretely, what needs do you have that
> aren't
> being met by Savannah?

Per-branch access control

> I don't understand this.  It seems to me the opposite.
> 
> If I want to contribute to this external 'wip' branch, I need to
> arrange
> for access.  Ditto for any other Guix committer who wants to work on
> it.
> That's added "bureaucracy" entailed by your approach that would not
> be
> needed for 'wip' branches on Savannah.

Cbaines is more responsive and has much lower requirements than what
the "Commit Access" for GNU Guix itself requires. It's as if we created
a third party git repo for both of us Raghav and myself then
collaborated there except through Cbaines's infra we get CI
infrastructure for free.

> On the other hand, maybe your point is that you'd like to allow
> direct
> commit access to this 'wip' branch by people who don't have commit
> access to Savannah.  If that's the goal, I find that objectionable,
> because when this branch is finally merged, all of those commits will
> suddenly get dumped into Savannah.  That increases "risk" from my
> perspective.
> 
> I actively do not want commits getting into Savannah without an
> existing
> Guix committer taking responsibility for them.  Your approach
> effectively creates a loophole for non-committers to potentially
> introduce many commits into the official Guix repository in a way
> that
> is likely to not get adequate oversight.

Why would it not get adequate oversight? It's just an easier way to
collaborate on patches, but the patchset would be sent over to guix-
patches before getting merged to master or else.

In general I don't agree with such gatekeeping of access to wip
branches because it actively hinders the development of GNU Guix by
non-committers, and many non-committers would like to get involved more
but they are barred by the commit access requirement.

> * * *
> 
> I'd strongly prefer for this work to be done on Savannah.  If this
> were
> a fringe branch of marginal interest, it might make sense to have it
> elsewhere, but this is core Guix desktop work that's likely to be of
> interest to a large segment (plausibly a majority) of our community.
> IMO, it belongs in our official git repository.
> 
> Thoughts?
> 
>   Mark

The people that work on it now are Raghav and me, and Raghav does not
have commit access yet, so that's the only way we can work and
cooperate now. We don't have a choice. If and when Raghav's commit
access application is approved then we can move to Savannah.

I don't feel like people should be barred to contribute to that GNOME
40 upgrade because they arent an approved committer. That doesnt feel
inclusive to me.

If you want to work on this GNOME upgrade however, that help is more
than welcome, in this 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

Re: GNOME 40

[Léo Le Bouter]

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 new committers so they can work on wip branches (shouldnt be
necessary).


signature.asc
Description: This is a digitally signed message part

Re: GNOME 40

[Léo Le Bouter]

If anyone is curious of the work or wants to participate, we are
working there: 
https://git.guix-patches.cbaines.net/guix-patches/log/?h=wip-gnome-40

The branch is based on core-updates and we will rebase it every now and
then, as well as merging patches to official core-updates as we feel it
is necessary.

cbaines gave us access to the git repo, it's not official so it's more
flexible, right now the access cbaines gives is all in and trustful,
but in the future they plan on getting branch access control with 
https://gitolite.com/gitolite/ so that people can be given access to
wip 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

Re: Document our WIP

[Léo Le Bouter]

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 changes depending on
> screen width: The primary menu is hidden behind a primary menu button
> for screens narrower than 920 px (which may be too soon already).
> 
> So, adding more primary items to that menu means the menu has to be
> hidden for even wider screens than 920. An that's from the English
> point of view only; I haven't checked how the header bar is behaving
> for other locales...
> 
> That said, I have a pending proposal to redesign the header bar to
> behave similar to headers in GNOME desktop applications (it could be
> simpler and follow already used conventions that people may be
> familiar with).

After looking more closely at the help page, I think it could be
acceptable to have it there too. But is the wiki an help resource?


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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.


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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 can set page
protection rules arbitrarily:

Page protection
EditAllow all users (infinite)
MoveAllow all users (infinite)

This is good, however creating new pages under WorkInProgress for
information on specific WIP projects or else looks like it would be
required for me.

Does someone know if we can do that on Libreplanet? Else I am afraid
this an arbitrary limitation harming our goal here.


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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 do that myself, nor that I would have authority to make such
change.


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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 digitally signed message part

Re: Cuirass not processing core-updates (or weirdly)

[Léo Le Bouter]

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

I think it may be because core-updates is setup to only build 'core and
not 'all.


signature.asc
Description: This is a digitally signed message part

Re: Document our WIP

[Léo Le Bouter]

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 ARM boards
> * ppc64 & ppc
> * Hurd VM
> * Full source bootstrap
> 
> And probably other things I missed.
> 
> This should complement the ML archives, IRC logs or
> blog, with pointers to (hopefully) more current infos
> on those subjects.
> 
> WDYT ?
> 
> [1] I only (accidentally) discovered today that those
> exist
> 

That would be really awesome, I suggest that we introduce such a
mechanism in a way that ANYONE can edit and that we moderate or filter
spam after the fact, not *before*. As gatekeeping in this way will make
the WIP documents edits grind to a halt and not be a viable solution.

We could use a wiki for this, but inspired by Wikipedia's model where
one does not need to register, or that registration is approved with an
easy process where many people have power to approve registrations so
registrations are never stuck waiting for approval. After such
registrations, users must be able to make unlimited edits to the wiki
as they wish. If there's problematic edits, we can moderate and filter
spam after the fact.

These are to me requirements for such an initiative to succeed.


signature.asc
Description: This is a digitally signed message part

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

On Sat, 2021-03-27 at 14:56 +0100, zimoun wrote:
> Oh, I am a big boy and I can think whatever I want! :-)
> 
> Kidding aside.

...

> 
> First, what does it mean «risk»?  How do you evaluate it?  Is it a
> relative evaluation or an absolute one?

Most if not all users do not want their machines to be compromised or
any side-effects of that.

> Second, I am not arguing that security is not important.  I am saying
> that security is important, as important as everything else that is
> also
> important.  What does it mean «important»?  How do you evaluate
> it?  Is it a
> relative evaluation or an absolute one?

Having security-updates branch or any other mechanism to ship security
updates promptly does not mean that the rest is not important.

> Third, I am aligned with Leo’s words [1].  And probably with yours
> too. :-) To me, a better security is not implied by special
> treatments for security fixes but instead a better treatment for the
> updates in general.

Security updates *need* special treatment. We already specially treat
them with grafts because it's an absolute necessity. We already have
private disclosure mailing lists in GNU Guix because security updates
need special treatment.

> 
> You are proposing a new branch and Chris and I are saying that this
> branch already exists and is staging.  The real question is to know
> how
> staging currently behaves: how many time between 2 merges?  how many
> 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 forward the arguments you've made, they do not work.

Léo


signature.asc
Description: This is a digitally signed message part

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

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 compared to a regular update.  That’s my opinion. :-)

You can't think this, security updates have prioritized channel of
distribution in every other GNU/Linux distribution, we in GNU Guix
created grafts for it, it's not possible to not ship security updates
promptly, it puts all users at risk.


signature.asc
Description: This is a digitally signed message part

Cuirass not processing core-updates (or weirdly)

[Léo Le Bouter]

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

Re: Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

On Fri, 2021-03-26 at 22:13 +, Christopher Baines wrote:
> Can you clarify what specific problem or problems you're proposing
> this
> security-updates branch to address?

Substitute availability of security updates when they are released,
without causing big rebuilds on master for users before the build farm
had time to produce substitutes.

> You mention applying and backporting patches is lots of work, and
> uncertainty around whether grafts work in particular
> situations.

Also that some times backporting is just not possible because security
fixes are not properly labeled upstream as security-relevant and manual
review of each and every commit is just not viable.

> Personally I think staging and core-updates are quite a bit of work,
> and
> adding more complexity to the process involves more work in my
> mind. Additionally, this isn't going to provide more information
> about
> areas where grafts can't be used (if those exist).

I understand. There's lot of uncertainty on how grafts work exactly for
me and in what situations they work and what situations they do not.
The only way I am certain some security fix is correctly applied in GNU
Guix is when the vulnerable version of the package is not packaged at
all anymore in GNU Guix.

> Now the software involved is getting better at rapidly building
> things
> for substitutes, personally I see a way forward through trying to
> measure and potentially increase the rate of change for outputs in
> general. Going faster also involves more work probably, but in terms
> of
> the process, that might just mean that updates to more packages can
> be
> merged to master directly, without sitting on a non-master branch.

I would like this, merging things to master 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 available.

Thanks for your input.
Léo


signature.asc
Description: This is a digitally signed message part

Security patching and the branching workflow: a new security-updates branch

[Léo Le Bouter]

Hello!

There is two ways to ship security fixes to packages:

1. Update to a patched version if upstream provides one
2. Apply or backport individual patches to fix the issues in the
shipped version

Grafts are most reliable for 2. but there's cases where using 2. is
lots of work and we can't afford that right now. An example is
ImageMagick where not all security issues get a CVE so essentially the
only way of getting security fixes is to fetch master or get the latest
release.

There's also some types of packages where we are not sure whether we
can use grafting or not, such as Python ones.

For these reasons, I would like to propose a new branch called
security-updates that would be based on master where we queue security
fixes that introduce any arbitrary number of rebuilds without using
grafts.

We would merge the security-updates branch as soon as there is complete
substitute availability for the branch and it's future merged version
within master.

The downsides of this approach are that:

1. Substitutes availability does not mean we can ship the updates
quickly because this might mean hundreds of megabytes if not gigabytes
of new substitutes to fetch to actually get the update.
2. Users that don't use substitutes will suffer big rebuilds on each
security update shipped through this branch.

For these reasons, grafting should still be preferred when possible,
but there are cases where it cannot be used for technical reasons or
lack of resources reasons but we still must provide a fix quickly.

What do you think?

Léo


signature.asc
Description: This is a digitally signed message part

Specify runtime dependencies with propagated-inputs or wrapper scripts

[Léo Le Bouter]

Hello!

I often meet problems where some packages don't work out of the box
because they have some runtime dependencies like themes or third party
programs.

I solved these problems on occasion by making commits such as this: 
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=00c1793ce8e2210e48b18422ea3e76da10541874
- which adds a wrapper script to "bin/chromium" and includes xdg-utils
in PATH variable.

It works but it's tedious to do for each and every binary in every
single package.

I see we also have a propagated-inputs field, which looks nice but for
some reason people advice against using it. For what reasons? It is not
as tedious as wrappers and I would really like to be able to specify
runtime dependencies of packages using it without problems.

I think we must find a solution to this runtime dependencies problem
that is better than wrapper scripts because they are very tedious to
create for every single binary in every single package.

Another recent example being that the caja package depends on dconf to
change it's settings, which is not installed by default when users use
window managers like sway.

Let's find a convenient solution here that would allow 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

Re: [opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

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 workstation-type 64-bit ARM
> > machines.
> 
> I already volunteered (privately) to host the same (1 or 2 WS power-
> class),
> currently on ADSL uplink (so not for substitute distribution, only
> building),
> FTTH in the future, no UPS though.
> 

I also have space at home, ~3500Mbps down, 600Mbps up, no UPS (yet?).


signature.asc
Description: This is a digitally signed message part

Re: I have merged wip-ppc64le-for-master to master

[Léo Le Bouter]

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, and I will update the "release"
> target
> of the Makefile so that we can make a release!
> 

Awesome Chris I am so happy we're finally there! Thanks a lot for
all the work you put in, always a huge pleasure to see people jump
aboard to collaborate on things you were/are working on!


signature.asc
Description: This is a digitally signed message part

A proposal for better quality in maintenance of packages by reducing scope

[Léo Le Bouter]

Hello!

There's lots of packages in GNU Guix and maintaining all of them is
tedious, even if we have tooling, there's only so much we can do.

I want to have a secure and reliable system, I would also like to only
depend on packages I know are easy to maintain for GNU Guix
contributors.

I would like to propose that we reduce the scope of the maintenance we
do in GNU Guix and establish a list of packages that we more or less
commit to maintaining because this is something that we can do and is
attainable, for example, we could remove desktop environments that we
can't maintain to good standards realistically and focus our efforts on
upstreams that don't go against our way of doing things, that are
cooperative, that provide good build systems we can rely on for our
purposes, etc.

I propose we also add some requirements before packages can go into
such a maintained state, like a working and reliable updater/refresher
with notifications directed to some mailing list when that one finds a
new release, a reduced amount of downstream patches and a cooperative
upstream with who we preferably have some point of contact to solve
issues or gather more insider knowledge about the software if we need,
a working and reliable CVE linter with proper cpe-name/vendor and
notifications going to a mailing list we all subscribe to, etc..
probably lots of other things are relevant but you see the idea.

It should also be possible to filter out packages that are not declared
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

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

On Tue, 2021-03-23 at 15:22 +0100, Andreas Enge wrote:
> I wrote in my bug report https://issues.guix.gnu.org/47315; grafts
> with
> different version numbers lead to a command line behaviour that is
> not
> understandable:
> 
> $ guix package -A imagemagick
> imagemagick   6.9.12-2g   out,doc gnu/packages/imagemagick.scm:132:2
> imagemagick   6.9.11-48   out,doc gnu/packages/imagemagick.scm:48:2
> 
> $ guix build imagemagick@6.9.11
> guix build: error: imagemagick: package not found for version 6.9.11
> 
> $ guix build imagemagick@6.9.11-48
> /gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
> /gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g
> 
> From a user's perspective, inkscape@6.9.11 is at the time there and
> not
> there; it is shown by "guix package", but then not accessible for
> install-
> ation, but silently "glossed over" in favour of a different version.
> 
> I just noticed that I can do this:
> $ guix build imagemagick@6.9.11-48 --no-grafts
> /gnu/store/wlnciwhn6llwqwywf4hq739v5bbcrq3h-imagemagick-6.9.11-48-doc
> /gnu/store/vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48
> But I can also do this:
> $ guix build imagemagick@6.9.12-2g --no-grafts
> /gnu/store/4s20df0zjmmys8zvlvynksrwz5xqk9ls-imagemagick-6.9.12-2g-doc
> /gnu/store/7iwx7rj1ipsbgb9wgimrrflniyxpilw3-imagemagick-6.9.12-2g
> where I do not know what I would have expected - the ungrafted
> version
> of 6.9.12 is 6.9.11, no? At the same time, for once it respects my
> wish for a specific version.
> 
> Otherwise said, grafting to different versions breaks our semantic
> for
> designating packages, in which version numbers play an important
> role,
> and replaces it by a mess which even with the examples above I have a
> hard time understanding.

For this, the problem is not grafting but that the replacement package
definition has been made public, this is an "issue" (?) that is known
and I try to not make replacement package definitions public now.

>  
> Caeterum censeo:
> The real fix is probably to do less grafts and more rebuilds...

Agreed, I would really like a security-updates branch for that, with
which we can buffer changes waiting for substitutes and then merge 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

Re: Let's include powerpc64le-linux in the next release

[Léo Le Bouter]

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’ to do that.
> 
> However, since we won’t be providing substitutes, we should label it
> as
> “technology preview” in the manual (info "(guix) GNU Distribution").
> 
> How does that sound?
> 
> Ludo’.

Sounds good!

Ludo, what is your SSH public key so I can give you access to the
powerpc64le-linux machine nckx has gotten from OSUOSL?

Thank you!


signature.asc
Description: This is a digitally signed message part

Secure GNU Guix offloading

[Léo Le Bouter]

Hello!

I have powerful machines at hand and I would like to share them through
the GNU Guix offloading facility so that they are easy to use.

The problem is that setting up offloading requires my machine to trust
each and every client's store public key which means they can spoof
results of derivations with malware.

I am not entirely sure of how it works internally but I was thinking
that instead of copying results of derivations over there could be a
"Secure offloading" mode where instead of copying store items it would
copy the derivation and ask to rebuild them on the offload machine
instead. It will be less efficient but at least it will be safe to
share a single powerful machine with multiple GNU Guix hackers.

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
Guix offloading so it can work even without the offload machine
trusting the client's store public signing key.

Another thing is that it would be nice to have greater granularity on
what you trust some store signing keys for, as in, you would want to
use the offload machine for some development work but you wouldnt want
to allow the offload machine to add malware to your own store. I am
thinking the GNU Guix VM machinery can be used to create a copy-on-
write store (through virtio-fs I think?) whose every modification gets
destroyed on VM shutdown or destroy (which looks great security-wise),
and this already works 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

Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

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 upstreams who either do not backport fixes, or don't
integrate fixes at all.

That's how I feel I can keep up with fixing security issues in GNU Guix
considering how overworked we are in general.


signature.asc
Description: This is a digitally signed message part

Re: Make guix commands pipeable

[Léo Le Bouter]

> 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 digitally signed message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

Hello!

> Removing a package and its services is not something to do lightly:
> it
> breaks user configs with no recourse.
> 
> We must insist on getting more opinions on such matters, and I think
> there just wasn’t enough feedback here.  I understand it can be
> frustrating to wait for input, but in such a case, please do.  This
> project has always strove for consensus.
> 
> Remember that the opinion of those who’ve been taking care of
> security
> issues in Guix for years, those who’ve been maintaining MongoDB,
> those
> who wrote the service and its tests, are invaluable; they must have a
> say.  I insist: humbly solicit and wait for their feedback.
> 

I understand, and I did not think it was a light thing to do, no one
mentionned anything we should do for the remove, so I actually do not
know how we handle that but the security/non-free code thing put some
urge into the situation, apologizes for moving on and pushing without
waiting for more feedback, few people gave their feedback on IRC and by
email and that's why I felt more confident doing the actual change.

> Now, how do we move forward?  IMO we must look for available options
> before we remove MongoDB.  Are there forks of the original
> freely-licensed code base maintained around?  That sounds likely.  

I never heard of any and after some searches even before I pushed the
remove commit it remained inconclusive on whether we can rely on a
fork.

> Are
> there backports of the security fixes? 

Ubuntu Focal maintains a package still but to me they still don't have
all the fixes, see: https://packages.ubuntu.com/focal/mongodb-server

All in all, I don't think we should keep a package in more-than-
maintenance mode when the upstream has decided to change the license,
they are uncooperative and making our work harder so I think we should
remove the package. It's not like we are an LTS distro like Ubuntu
Focal that absolutely must keep a package until the end of the support
cycle. It may break configs yes, but actually this had to happen, at
the same time they changed to a problematic nonfree license and openssl
1.1.1 is not supported on 3.4.x (Ubuntu uses 3.6.8 instead which also
is under AGPL but more recent than our 3.4.10 we had so supports
openssl 1.1.1 with some patches they made). I'm not particularily
sympathetic to MongoDB. 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 wait
for their input here.

> 
> Léo, please get involved in reaching consensus on a solution.

CC'd them, of course, again, sorry.

> Ludo’.

Léo




signature.asc
Description: This is a digitally signed message part

imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2

[Léo Le Bouter]

Hello!

See commit: 82e887ba48c2ba91b17aa9b6b17501e3e0ef4aef

Following discussion around whether it is safe to graft and whether we
should do so or not, first, I apologize for not doing as rigorous
checking on this issue as I should have, and also requesting more peer-
review, I initially believed those two ImageMagick version were ABI
compatible with unchanged soname so it turns out it would be a rather
uncontroversial graft to make but now it turns out we have a changed
soname but whether it is binary (backwards) compatible or not remains a
question.

We had a user reporting that Inkscape stopped working after the graft (
https://logs.guix.gnu.org/guix/2021-03-18.log#100200), after which we
decided on IRC with rekado we might cheat by symlinking the shared
libraries, which I've done in commit
2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd, from a glance it didnt seem
the soname change caused backwards incompatible changes but only
forward incompatible changes.

Let's see some abidiff output now:

$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagickCore-6.Q16.so.6 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickCore-6.Q16.so.7
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable
Function symbols changes summary: 0 Removed, 0 Added function symbol
not referenced by debug info
Variable symbols changes summary: 0 Removed, 1 Added variable symbol
not referenced by debug info

SONAME changed from 'libMagickCore-6.Q16.so.6' to 'libMagickCore-
6.Q16.so.7'

1 Added variable symbol not referenced by debug info:

  [A] .gomp_critical_user_analyzeImage


$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagick++-6.Q16.so.8 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagick++-6.Q16.so.9
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

SONAME changed from 'libMagick++-6.Q16.so.8' to 'libMagick++-
6.Q16.so.9'

$ ./pre-inst-env guix environment --ad-hoc libabigail -- abidiff
$(./pre-inst-env guix build --no-grafts imagemagick@6.9.11-48 | grep -v
doc)/lib/libMagickWand-6.Q16.so.6 $(./pre-inst-env guix build 
imagemagick@6.9.12-2g | grep -v doc)/lib/libMagickWand-6.Q16.so.7
ELF SONAME changed
Functions changes summary: 0 Removed, 0 Changed, 0 Added function
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

SONAME changed from 'libMagickWand-6.Q16.so.6' to 'libMagickWand-
6.Q16.so.7'

Any more ABI diff-ing/testing, information, etc.. on whether this is
safe or not is welcome, it sounds to me it could be fine but there is
some amount of doubt still.

If we can't graft ImageMagick we shall revert 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 message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

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 we did not know pushing a security fix with 3.4.24 was not
fine, from quick auditing I have made 3.4.24 would still be under AGPL
so it would be fine to upgrade, turns out not since some files inside
are under SSPL but that was discovered way later, even when Efraim had
doubt and reverted my commit we had a debate and Efraim bought my
arguing even though I was wrong and they were right, if for every
security issue I have to ask feedback I may not ship them in a timely
manner, so that's also why they tend to be pushed faster than usual..
we may want to establish a clear process here. I usually create issues
for things I need help on, if I can do it myself and feel confident, I
just push, I can be wrong of course and always sorry for issues, I fix
them shortly in next commits if any.


signature.asc
Description: This is a digitally signed message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

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 wrong and instead of reverting the revert of the
revert of Efraim the next change was removal because of other reasons.

Besides the openssl issue I think the commit message laid out these
things quite well.


signature.asc
Description: This is a digitally signed message part

Re: Rust and parametric packages

[Léo Le Bouter]

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 disabled. If this and the compiler
> version are truly the only variables to consider, we could just lift
> the features to the package level, right?
> 
> https://lists.gnu.org/archive/html/guix-devel/2021-02/msg00269.html
> 

I advise you look there also: 
https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rlib-intermediate-object-reuse/near/225653640


signature.asc
Description: This is a digitally signed message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

On Wed, 2021-03-17 at 18:56 +0100, zimoun wrote:
> AFAIT, 3.4.10 is released under GNU AGPL 3.0 and Apache 2.0.  This
> version had been released before the October 16th, 2018.  Could you
> point which code is non-free?
> 
> IMHO, this claim about non-free code is wrong.  The last versions
> with
> an acceptable license seem 4.0.3 or 4.1.4, I guess.

It's not wrong, look at 2f9132e2e0b1e01398a01a32972e87f45ec2f7a6, we
were shipping 3.4.24 before the removal, not 3.4.10.

> I am not against removing MongoBD.  I am just saying that the removal
> deserves at least a message on guix-devel and maybe a --news entry.
> 
> Other said, it deserves more than 6 days between the “oh there is
> security vulnerabilities” and the full removal.  When one uses a
> version
> from 2017 as 3.4.10 is, one knows that it can have security
> vulnerabilities.
> 
> I am not complaining about the commit itself, but I am complaining by
> the way of doing the thing.

I agree, will do differently in the future, no one mentionned it during
all discussions, but if it was I would've, 3-4 days did not give you
time to comment so I'll wait longer maybe re-re-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

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

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 would be to work on improving it.
> 
> If you look at Guix’s design and history, you’ll find that much is
> built
> in a way that avoids relying on external services when we can.

Just to clarify, I also get behind that very much I was suggesting the
functional part more so than the service kind, even though I think
services (like Guix Data Service) are OK as long as datasets are easily
exportable and the service itself can easily be re-deployed through GNU
Guix as well.

It seems GNU Guix takes a generic approach to updates while Debian or
Fedora seems to look at specialized rules for each package, I was
thinking we could import those already existing rules (in Fedora's or
Debian's) into GNU Guix, I find it a superior approach for reliability
of notifications even though generic updaters are also very
complementary.


signature.asc
Description: This is a digitally signed message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

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
> solution (especially, it should be done with 2 commits: service+doc
> and
> then package; well another story).

Another thing is that openssl 1.1.1 on non-SSPL mongodb doesnt work and
we are working on removal of openssl 1.0.x which will removed all it's
dependents and mongodb is one so it was inevitably going to be removed
anyway.

> All the best,
> simon


signature.asc
Description: This is a digitally signed message part

Re: Why [bug#47081] Remove mongodb?

[Léo Le Bouter]

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
> solution (especially, it should be done with 2 commits: service+doc
> and
> then package; well another story).

https://issues.guix.gnu.org/47081 - some of it there: 
https://logs.guix.gnu.org/guix/2021-03-12.log#001752

Efraim, Cbaines, Lfam was involved there and shown no big objections

> 
> Well, you updated mongodb from 3.4.10 to 3.4.24 on the March 10th,
> submitted a patch series for the removal on the March 12th and pushed
> on
> the March 16th.  In the meantime, the update has been reverted on the
> March 11th because of license issue, IIUC.
> 

The security update 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 made it kind of stressful

Léo


signature.asc
Description: This is a digitally signed message part

Re: Are gzip-compressed substitutes still used?

[Léo Le Bouter]

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

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

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 relevant data, although I'm also thinking along the lines of
> trying to generate patches, like you go on to below...

Yes :-D

> So, one thing I'm hoping to start work on in the coming weeks/months
> is
> the long awaited service for providing subscriptions/notifications
> for
> the Guix Data Service (+ other services).
> 
> My current plan is to use a WebSub like pattern, but this could
> easily
> be adapted to RSS/email/...

That sounds very great! I know you've been working on this, but I also
wanted (through my email) try to make more people aware and draw
attention to the subject of automation in GNU Guix.

> Yeah, one problem with the current automated patch review stuff I've
> got
> going at the moment is that there's no feedback when the Guix Data
> Service finds out that things do/don't build.

Yes, and because of that the Guix Data Service and guix-build-
coordinator-agent thing you are running goes mostly unused (even for
me!).

> However, as I also set out above, there's been a plan and design for
> making that possible for years, it just needs implementing.
> 
> One thing I'm hoping to do once it's possible to subscribe to Guix
> Data
> Service data is make the checks in Patchwork actually reflective of
> results (like 4 packages broken by these changes), rather than just
> providing links, and someone having to figure out what information is
> hidden within.
> 
> Those same subscriptions could be used to prompt people to look at
> patches for package updates that don't introduce breakages (following
> what you set out above).

+1000

> The pieces are slowly coming together for this, at least with the way
> I
> would approach it. For example, it's possible to get commits in to
> data.guix-patches.cbaines.net now by just pushing to the Git
> repository,
> so to set out something similar to what you describe above:
> 
>  - Some service watches for new releases (through the guix refresh
>code), and then makes commits, and pushes them to a Git repo
> 
>  - There's a Guix Data Service reading from that Git repository, it
>starts processing the changes
> 
>  - Something (probably the "service" above") subscribes to find out
> when
>relevant information is available (like build successes/failures)
> 
>  - Builds happen via the Guix Build Coordinator, which feeds
> information
>back to the Guix Data Service
> 
>  - That "service" gets the notifications that the commits are good,
> and
>prompts someone to review them

All awesome! Can't wait! As soon as I can I will make sure to help, I
am reading through the GNU Guile manual, need to find more
concentration time.

> I hope some of that makes sense,
> 
> Chris

Thanks a lot Chris for all this!!


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

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 work, I
didnt manually backport any patch (or only some with trivial changes
that can be made by manually editing the patch file), I don't feel I
deserve such thanks, even if they are appreciated, and we are all to be
thanked for our work, it's not that impressive, I think I just went
down with serious motivation looking at it and doing the repetitive
work there.

> I have the same request :-)  Please submit non-trivial patches for 
> review (and, unfortunately, grafts are hardly ever trivial).  This 
> isn't a comment on your work; it's our standard way of doing 
> things.
> 
> I know we're not the #1 bestest project when it comes to the swift 
> review of patches.  I understand the sense of urgency in fixing 
> things that one feels should have been fixed long ago.  Thank you 
> for helping us to improve on both points.

I understand, I am sorry for unsolicited breakage anything might have
caused, I will try to put it up for review, I already do try, zstd was
one of my earlier grafts, I did realize even by myself that after
pushing it I was touching a very critical part of GNU Guix and it
would've been better maybe to ask for review before.

> Kind regards,
> 
> T G-R

Léo


signature.asc
Description: This is a digitally signed message part

Re: Security-czar needed? WAS: Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

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 prevent
> applying unreviewed patches, and making sure all CVEs are taken
> care of, and kitchen doors not left open the way we did in the '50s.
> 
> Sorry if it sounds like I think guix security is lax.
> Please convince me it's not so ;)
> 
> Thanks, nevertheless, for all the great technical work!
> 
> Just wish I could type
> guix --what-and-who-am-I-trusting-q --full-report
> and get a complete list, with batting averages of the
> developers (regressions vs fixes), packages (estimated
> number of times executed without problem, dangerous bugs
> in development history, etc).
> 
> 
> 

I think we can handle this without granting us any special powers, I
like it that we don't have roles actually!

We can discuss, debate, agree to common goals, I don't think we are
going to enter into conflict, we hear each other, we communicate, I
think that's a really good thing in GNU Guix :-D

Lots of other communities enter into conflict fast and stop
communicating, GNU Guix is not that, there's a spirit of goodwill of
everyone and that's really pleasing to live as a contributor and user.


signature.asc
Description: This is a digitally signed message part

Re: [opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

Sorry for duplicated email..

On Tue, 2021-03-16 at 19:19 -0400, Mark H Weaver wrote:
> If not, it would be good to work toward the goal of making Guix
> usable
> on non-Intel systems.  I'm sorry to say that, in my opinion, your
> proposal would move us in the wrong direction to achieve that goal.

We have been working with Chris Marusich, Efraim and numerous others on
porting GNU Guix to PowerPC 64-bits, I think both are not
contradictory. I have a Talos II desktop at home which once GNU Guix
works on it will be the main machine I will use to contribute to GNU
Guix (along with offloading to other machines for testing on other
archs), so count on me to at the same time keep up on GNU Guix and test
things on PowerPC 64-bits.

I am of course concerned with any blob doing things I don't need (and
introducing security risk) under the hood, that's why (along with
strong software freedom imaginaries) I pre-ordered my RaptorCS Talos II
machine in 2017 and that I have been trying since 2 years to bring
PowerPC 64-bits to GNU Guix (also with numerous other folks who joined
efforts most recently Chris Marusich who've been enormous help!).

But I also want to be realistic that the major security risk in most
computers today probably isnt the Intel ME or Intel AMT and that we
also can do many other things in the system itself that reduces risk
greatly. I'll be honest also, the IBM POWER chips have gotten much less
security review than the Intel or AMD chips recently, so it's not
because there's not as much security drama on IBM POWER that it doesnt
have (maybe even more severe) issues :-)

About the overall security of GNU Guix and the things we can do that
don't involve keeping a fast-paced rythm to updating packages I see few
things, right now GNU Guile is the center of all's GNU Guix security, I
am not sure it received lots of security auditing, it's also written in
part in a memory-unsafe language that is C, so there's probably some
low hanging fruits there once some starts fuzzing it, I'm no big expert
in fuzzing but I may try at some point.

I think we can do many things complementary, prevention (sandboxing),
mitigation (enabling hardening compiler flags, ..), AND code security
patching. The first two don't require we keep a fast paced update
rythm, also we may do the first two especially because we realize we
can't do the latter at all time and I realize that, I just think we
should always try to, at least, that's all.

I am also a bit concerned with the idea that GNU Guix, GNU Shepherd
etc. execute code from arbitrary files in many places, I am not sure
all the security details have been reviewed here, it seems risky to me
to have configuration 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 digitally signed message part

Re: [opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

On Tue, 2021-03-16 at 19:19 -0400, Mark H Weaver wrote:
> That said, I strongly disagree that we should "never backport patches
> ourselves in most cases".  The only way to do that, while addressing
> security flaws, would be to promptly update even our lowest-level
> libraries in response to CVEs, of which there is a steady stream.

Fortunately I think that lots of these core package upstreams also have
good CVE-issuance practices. For the Glib care in particular, I think
they are good, I consider acceptable to backport patches, everyone is
doing it, upstream is cooperative and works towards that same goal.

To everyone else in general, I understand we have to ship a working
system, and I want that too, that's why I said we should "strive" to,
but it doesnt mean we should break things, of course. By that I mean
that we shouldnt leave packages unmaintained without updates for too
long even without CVEs or other security notices issued. At some point,
if a package is of no use, no users show up and it's painful to update,
we should also consider removing the package or archiving it in a third
party channel we could create like "guix-archive", "guix-ugly" or
"guix-love-me-please".

Léo


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

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 patches include fixing typos,
> etc.). […]
> 
> For patches that just add a new package, and a simple one,
> it’s OK to
> commit, if you’re confident […].  Likewise for package
> upgrades, except
> upgrades that trigger a lot of rebuilds […].
> 
> […]
> 
> […] If you didn’t receive any reply after two weeks, and if
> you’re confident, it’s OK to commit.
> 
> 
> 
> And from my understanding, it is a non-trivial patch which triggers a
> lot of rebuilds.  Double reasons. ;-)

It's not just like any other patch, it's a security patch, so **15**
days..

> 
> Cheers,
> simon


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 19:19 +0100, zimoun wrote:
> I guess that it will not build for i686.  Does it?
> If not, the patch attached to the previous email tweaks the offending
> test; as the original author of zstd has suggested:
> 
> 
> 
> (Thanks to the other Leo for opening the issue.)

Indeed it would not pass tests, thanks for the patch.

> 
> Well, I am confused.  If the update of zstd from 1.4.4 to 1.4.9 does
> not imply a huge rebuild, why is it a graft?  And not a simple
> update?

Well there is some huge rebuild involved, but there is something else
happening here, the zstd package as a specification now refers to 
zstd@1.4.9 and not zstd@1.4.4 (as grafted) because the version is
newer, I should've made the zstd@1.4.9 graft package definition private
here as I do now for other grafts.

$ ./pre-inst-env guix refresh -l zstd
Building the following 2 packages would ensure 2 dependent packages are
rebuilt: ecl-zstd@1.0-1.d144582 cl-zstd@1.0-1.d144582

We see only 2 here, but it's a false result, zstd is a dependency to
way more,

Then if we do this:

$ ./pre-inst-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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 13:55 -0400, Leo Famulari wrote:
> I do agree that updating this program 5 versions in a graft was
> perhaps
> too much.
> 
> We should always try to cherry-pick bug-fix patches when grafting.
> 
> Otherwise the risk of breakage is too high. At least, these 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
believed it wasnt risky. I can send them to the mailing list especially
with such a core package (GNU Guix dependency). But often it stays
there and no one is looking so. E.g. the unzip vulnerability patches,
nobody looked until I actually pushed them out of waiting for reviews,
I tried to hint multiple people on IRC during several days, no answer
still, so I ended up pushing it, turns out I had several mistakes in it
and because it was pushed well some people looked at it and helped
fixing which was welcome.


signature.asc
Description: This is a digitally signed message part

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

On Tue, 2021-03-16 at 13:48 -0400, Leo Famulari wrote:
> This is off-topic, but I think that CVE scoring is not really that
> useful. This bug is a local TOCTOU race which is bad but hardly
> critical, IMO. For something to be critical, it should enable remote
> execution of arbitrary code.

Well you don't know what people use zstd for, easily escalates to more
critical issues depending on people's use case. Also I think CRITICAL
reasoning here is also because it's a trivial to understand and exploit
issue, it's not like an obscure memory safety issue with no known PoC
but probable exploitation.

I do not agree in general not patching CVEs even if low (publicized)
severity as long as it's possible for us to do it. Often the
vulnerabilities have an unobserved attack angle and severity may be
underevaluated. The zstd patch was tested on x86_64-linux it's
unfortunate the test suite fails (errornously, not an actual fault) on
32bit archs, otherwise it's no issue. I wish the zstd test suite was
more reliable in general, generating random data in their test suite
doesnt help determinism here. I think I tried on i686-linux to build as
well and it succeeded for me so I pushed, but it didnt fail on me and
when I retried later it did, so definitely some non-determinism here.

Since we know there's no actual fault in the test suite because it
passes I thought it was relatively fine to disable the test suite
temporarily until core-updates comes in (if we don't change versions in
between and revisit).

Zimoun:
> which fails for the value 19 but not other values as 18 or 20 or many
> others.  After a quick reading of the doc, I am not sure to
> understand
> the meaning of such value.  Input welcome.

https://github.com/facebook/zstd/issues/2528 - I asked upstream earlier
and see their answer

> I agree that security is important but we lived more than one and
> half
> year with 1.4.4 so the upgrade to 1.4.9 should only go to
> core-updates, not as a 'replacement' graft.  IMHO.

To add, I don't think we should reason that way, it's not because 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

Re: Release 1.2.1: zstd 1.4.4 -> 1.4.9: grafting or core-updates?

[Léo Le Bouter]

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

Re: Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

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 every package so we can get reliable (in majority of
> > cases)
> > update notifications.
> 
> “guix lint” has a checker for releases:
> 
> --8<---cut here---start->8---
> $ guix lint -l
> Available checkers:
> […]
> - refresh: Check the package for new upstream releases
> --8<---cut here---end--->8---
> 
> It just needs to be extended to cover more packages.
> 
> Developing a service that runs this for all packages is an orthogonal
> issue.
> 

Just to clarify, I do know it exists and use it often :-)
Indeed it needs to be extended and that's what I am talking about
there, also Guix Data Service is important here because we cannot
possibly each on our sides spam the various URLs or APIs to generate
the release monitoring dataset. Instead, using Guix Data Service for
that with specially configured API keys and else sounds like a better
idea.


signature.asc
Description: This is a digitally signed message part

Re: [opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

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 those stuff not easier and is maybe the third
> reason/root issue...

I agree with all 3 points. I have hope however that we can develop
better tooling over time to ease the burden on us so we can devote more
time to tasks that actually absolutely **require** our human oversight
to be done. And then even without an increase in the contributor base
we can avoid lagging behind on these updates.


signature.asc
Description: This is a digitally signed message part

[opinion] CVE-patching is not sufficient for package security patching

[Léo Le Bouter]

Hello!

I would like to share some opinion I have on CVE-patching for non-
rolling release GNU/Linux distributions and why we should strive to
always update to the latest available releases or always follow
upstream supported release series and never backport patches ourselves
in most cases (some upstreams may have really good practices but these
are rare).

A lot of security issues are patched silently in upstream projects
without ever getting a CVE, security issues may not be labeled as such
by upstreams for various reasons (fear of shame, belief to patch
something with no security impact while it has, bizarre security
through obscurity policy, ..).

For these reasons, I suggest that we always strive to update packages
to their latest versions and that I think it is security relevant to
always do so. Of course, new code could *introduce* new vulnerabilities
but I am not trying to debate this, it's that to the best of the
upstream's knowledge chances are that the latest version will contain
more security fixes than older versions (if that upstream is actually
maintaining the project).

In many cases, browsing through the commit history of some popular
projects can uncover security issues not publicized through any
security mailing lists or CVEs anywhere, this is unfortunately quite
common. We cannot possibly monitor the commit history (and code) of
every single project to backport fixes when we would need to. It is
better for us to always strive to use the latest versions 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

Fedora/Debian release monitoring inspiration for Guix Data Service

[Léo Le Bouter]

Hello!

It seems Fedora has automated infrastructure and feeds to monitor new
upstream releases so that maintainers can get notifications on them.

https://release-monitoring.org/

Functional feed: 
https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1=127800=hotness

I could not find the actual data it is based on for release monitoring
(like Debian watch files).

I could not find a similar feed for Debian's watch/uscan but it would
be nice if they provided some sort of RSS feed (global or scoped to
packages or sets of packages).

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 every package so we can get reliable (in majority of cases)
update notifications.

We could also have some feature that gives you a feed for a manifest or
operating-system definition so that people can prioritize work on what
they care about easily.

I would really love to have some RSS feed for new upstream releases
from Guix Data Service based on my operating-system definition I would
upload there.

We could even go as far as preparing a patch (similar to guix refresh
-u  && etc/committer.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 efficient workflow). 

Léo


signature.asc
Description: This is a digitally signed message part

Re: Let's include powerpc64le-linux in the next release (was: Re: Release on April 18th?)

[Léo Le Bouter]

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 invoking "make guix-binary.powerpc64le-linux.tar.xz"
> > themselves.  However, for convenience, it would be nice to provide
> > a
> > pre-built binary if possible.  Shall I build this myself when the
> > time
> > comes, or would people prefer to do it a different way?
> > 
> 
> When aarch64 support was very new I gave ludo access to my board and
> he
> offloaded the build to it.
> 
> 

We have one ppc64le VM from OSUOSL which would qualify as "GNU Guix
owned" that nckx, myself, Efraim and Vincent Legoll have access to, so
we should definitely use that. We will be working into having that VM
added into Cuirass CI as soon as possible after merge into master too.


signature.asc
Description: This is a digitally signed message part

Re: GNU Mes 0.23 released

[Léo Le Bouter]

Thanks a lot! Keep it up! :-D


signature.asc
Description: This is a digitally signed message part

Re: Guile Netlink 1.0 released

[Léo Le Bouter]

Exciting new possibilities! Great work!


signature.asc
Description: This is a digitally signed message part

Re: gnutls package may be vulnerable to CVE-2021-20232

[Léo Le Bouter]

On Sat, 2021-03-13 at 05:12 -0500, Mark H Weaver wrote:
> I pushed fixes for this and CVE-2021-20231 to 'master' in commit
> 74e2c0e00f58c8bf948f7dc7c5ae2876af910d5a.

Thank you, I would otherwise have done it, I was waiting for an answer
from upstream first, or some time.

> For what it's worth, I think that  would be a more
> appropriate place to send these bug reports.  What do you think?

I don't know, it seems people read guix-devel more maybe? I don't know
if they are bug reports, most of the time I am handling these issues
myself, I just try to keep a public log so I 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

gnutls package may be vulnerable to CVE-2021-20232

[Léo Le Bouter]

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 <
https://gitlab.com/gnutls/gnutls/-/issues/1151#note_528567535>. Let's
wait for an answer, or then apply/backport this commit (
https://gitlab.com/gnutls/gnutls/-/commit/75a937d97f4fefc6f9b08e3791f151445f551cb3
) to 3.6.x series.

A rather low impact vulnerability upstream says, but I would be careful
there as an experienced exploit writer could find reliable ways to
exploit it in my opinion.

Let's patch this as soon as possible!


signature.asc
Description: This is a digitally signed message part

libupnp package vulnerable to CVE-2021-28302

[Léo Le Bouter]

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 <
https://github.com/pupnp/pupnp/issues/249>.

I suggest we wait for the patch to be made and then update, to be
monitored.


signature.asc
Description: This is a digitally signed message part

Re: glib vulnerable to CVE-2021-28153

[Léo Le Bouter]

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

glib vulnerable to CVE-2021-28153

[Léo Le Bouter]

Hello!

CVE-2021-28153  11.03.21 23:15
An issue was discovered in GNOME GLib before 2.66.8. When
g_file_replace() is used with G_FILE_CREATE_REPLACE_DESTINATION to
replace a path that is a dangling symlink, it incorrectly also creates
the target of the symlink as an empty file, which could conceivably
have security relevance if the symlink is attacker-controlled. (If the
path is a symlink to a file that already exists, then the contents of
that file correctly remain unchanged.)

Another CVE just out,

See: https://gitlab.gnome.org/GNOME/glib/-/issues/2325

We need to backport another patch again it seems?

Thank you,
Léo


signature.asc
Description: This is a digitally signed message part

Re: glib@2.62.6 is vulnerable to CVE-2021-27218 and CVE-2021-27219

[Léo Le Bouter]

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.
> 
> Done in commit 21b3b755151028647081fe96d2992b3743531d71 on the
> 'master'
> branch.
> 
>   Mark

Thank you!


signature.asc
Description: This is a digitally signed message part

Re: GNU Guix (pull?) on i686 broke after zstd grafting

[Léo Le Bouter]

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 anyone
running i686-linux or aarch64-linux/armhf-linux (it looked to fail
there also?).

Please fix the situation if you can, or I'll try and do it at some
point but can't say when, lots of things going on now.


signature.asc
Description: This is a digitally signed message part

Re: GNU Guix (pull?) on i686 broke after zstd grafting

[Léo Le Bouter]

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 1.4.9 (without
disabled tests) is in core-updates and we are waiting for upstream to
fix the test-suite, this change is not durable as it's a graft for a
security update.


signature.asc
Description: This is a digitally signed message part

Re: I've rebased wip-ppc64le onto core-updates

[Léo Le Bouter]

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.


signature.asc
Description: This is a digitally signed message part

Re: GNOME 3.34 in GNU Guix and security

[Léo Le Bouter]

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 you know
> of,
> and what makes you think that we can't address them adequately in the
> usual ways, without "upgrading GNOME to [the] latest"?

I have not yet fully investigated each CVE but there is uncertainty
around gnome-shell, gvfs, librsvg, gdk-pixbuf, pango, cairo, if not
more. You can use 'guix lint -c cve ' to find out, also look up in
NVD individually in case GNU Guix doesnt find it.

I am always uneasy relying on CVE only for security patches since I
know how much lots of security issues are fixed by developers without
issuing any CVE, so to me the best way of keeping up is to always be on
latest.

> I saw your bug report about our Glib being vulnerable to CVE-2021-
> 27218
> and CVE-2021-27219.  Thanks very much for bringing that our
> attention.
> 
> I'll backport the fixes to our version of Glib.  It will actually be
> quite easy, given that Ubuntu has already published backports of
> the
> fixes for Glib 2.56.4 and 2.64.4, which brackets the version in Guix
> (2.62.6).  I just looked at the diffs between those two patch sets,
> and
> the differences are quite slight, apart from line number differences.

I am really happy you are willing to help! I will have to admit that I
am a bit overwhelmed by the amount of work that I have left still.

Léo


signature.asc
Description: This is a digitally signed message part

2443 packages indirectly depend on unsupported openssl@1.0.2u

[Léo Le Bouter]

Hello!

$ ./pre-inst-env guix refresh -l openssl@1.0.2u
Building the following 2320 packages would ensure 2443 dependent
[...]

As upstream says at :
> Version 1.0.2 is no longer supported. Extended support for 1.0.2 to
gain access to 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

GNOME 3.34 in GNU Guix and security

[Léo Le Bouter]

Hello!

I must come to the conclusion that using GNOME 3.34 in GNU Guix right
now is just straight out insecure. I would advise we either, get rid of
GNOME, backport all individual security patches (they can be
numerous..), or upgrade GNOME to latest and keep up over time.

I don't think we can 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

pjproject package is vulnerable to CVE-2021-21375 and CVE-2020-15260

[Léo Le Bouter]

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
received, with the first one causing negotiation failure, a crash will
occur. This results in a denial of service.

CVE-2020-15260  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 version 2.10 and earlier, PJSIP
transport can be reused if they have the same IP address + port +
protocol. However, this is insufficient for secure transport since it
lacks remote hostname authentication. Suppose we have created a TLS
connection to `sip.foo.com`, which has an IP address `100.1.1.1`. If we
want to create a TLS connection to another hostname, say `sip.bar.com`,
which has the same IP address, then it will reuse that existing
connection, even though `100.1.1.1` does not have certificate to
authenticate as `sip.bar.com`. The vulnerability allows for an insecure
interaction without user awareness. It affects users who need access to
connections to different destinations that translate to the same
address, and allows man-in-the-middle attack if attacker can route a
connection to another destination such as in the case of DNS spoofing.

Upstream has not made a release yet, I advise we wait for a release on
their end then upgrade. To be monitored.


signature.asc
Description: This is a digitally signed message part