Re: purpose of GnuTLS versions

[Ludovic Courtès]

Hello!

Jack Hill  skribis:

> On Tue, 31 Jan 2023, Ludovic Courtès wrote:
>
>> Jack Hill  skribis:
>>
>>> Then there's the question of what to do in the meantime for
>>> master. Grafts for 3.7.2? Move packages to 3.7.7?
>>
>> Graft, after making sure both versions are ABI-compatible (it should be
>> the case).
>
> Unfortunately, we may not be so lucky. ABI Laboratory* reports that
> were some changes in 3.7.3 [0].

I would recommend checking by running ‘abidiff’ (from the ‘libabigail’
package) on our own binaries, to be sure.

If there are only additions (new symbols), which is what I would expect,
then we’re fine.  If there were deletions (unlikely), then we may have a
problem.

HTH!

Ludo’.

Google Summer of Code?

[Ludovic Courtès]

Hello Guix!

Jose Marchesi applied to have GNU participate as an umbrella
organization in GSoC:

  https://lists.gnu.org/archive/html/summer-of-code/2023-02/msg0.html

Participation in internship programs was discussed at the Guix Days and
quite a few people were enthusiastic about resuming participation in
these programs.

I think we could submit project ideas as Jose outlines in the message
above, possibly starting by collecting them on a wiki page as we did in
the past.  For reference, this is what we had in previous years:

  https://libreplanet.org/wiki/Group:Guix/GSoC-2021
  https://libreplanet.org/wiki/Group:Guix/GSoC-2020

Who would like to coordinate that effort and/or offer to mentor a
specific project?

(I am not offering to do any of these :-) but I’m happy to provide
feedback or share my experience regarding mentoring.)

Ludo’.

Re: What's the state of (guix build download-nar)?

[Ludovic Courtès]

Hi Chris!

Christopher Baines  skribis:

> I guess this raises two things in my mind. I'm not sure this'll work
> well given the not so recent changes to ci.guix.gnu.org. This module
> looks to rely on gzipped or uncompressed nars. I'm not sure uncompressed
> nars are available, and gzipped ones are no longer available.
>
> The second question is around the relation to bordeaux.guix.gnu.org, is
> it worth trying to support fetching nars from bordeaux.guix.gnu.org
> here, and what would be the best way of doing that? It wouldn't be too
> hard to add support for decomressed nars I think if that's a good
> approach?

Uh, that module needs love indeed.

Currently it’s used by some of the (guix VCS-download) modules.  I think
we should just update to (1) use lzip instead of gzip, and (2) have it
check ci.guix.gnu.org + bordeaux.guix.gnu.org.

Would you like to give it a try?

Thanks,
Ludo’.

Re: What's the state of (guix build download-nar)?

[Christopher Baines]

Ludovic Courtès  writes:

> Hi Chris!
>
> Christopher Baines  skribis:
>
>> I guess this raises two things in my mind. I'm not sure this'll work
>> well given the not so recent changes to ci.guix.gnu.org. This module
>> looks to rely on gzipped or uncompressed nars. I'm not sure uncompressed
>> nars are available, and gzipped ones are no longer available.
>>
>> The second question is around the relation to bordeaux.guix.gnu.org, is
>> it worth trying to support fetching nars from bordeaux.guix.gnu.org
>> here, and what would be the best way of doing that? It wouldn't be too
>> hard to add support for decomressed nars I think if that's a good
>> approach?
>
> Uh, that module needs love indeed.
>
> Currently it’s used by some of the (guix VCS-download) modules.  I think
> we should just update to (1) use lzip instead of gzip, and (2) have it
> check ci.guix.gnu.org + bordeaux.guix.gnu.org.
>
> Would you like to give it a try?

That approach sounds good to me, I'll have a look at drafting a patch.

Thanks,

Chris


signature.asc
Description: PGP signature

Re: Protect against 'guix pull' providing stale data

[Ludovic Courtès]

Hi Simon!

Simon Josefsson via "Development of GNU Guix and the GNU System
distribution."  skribis:

> I was watching
>
> https://fosdem.org/2023/schedule/event/security_where_does_that_code_come_from/
>
> and one concern that came up was that there is no protection or
> mitigation against 'guix pull' servers providing machines old data, to
> (for example) stall security updates from reaching a server.  Currently
> the Savannah sysadmins have the power to delay security updates for my
> machine.  I think this should be considered a unwanted behaviour that
> warrant some action, either tooling improvement or documentation.

Right, it’s a limitation of this model (and of Git in general).  This is
mentioned in 
(Section 7 discusses that in the context of mirrors, and Related Work
mentions the “reference state log” mechanism proposed by Torres-Arias et
al.).

> There are many ways to improve the situation, even though addressing the
> problem completely is difficult (most if not all GNU/Linux distributions
> have similar issues).  Some ideas:
>
> * Warn if the repository has not since a commit for > 7 days, with the
>   delay being configurable.  This may be a bad idea: warnings are
>   generally not appreciated by users, security warnings specially so.

Yeah.

> * Have 'guix pull' show metadata for the last commit it received (e.g.,
>   show output from: git log -1) to give users a way of noticing that it
>   is not seeing new data.  Currently only the git commit id is shown
>   which does not convey enough information.

Right, but commit timestamps wouldn’t help either: with the current
backlog, we regularly push one-month-old patches.  :-)  Expecting users
to judge freshness on their own doesn’t sound piratical to me anyway.

> * Adopt a way for repositories to state the validity period of its
>   content to have the 7 days a bit configurable, compare for example:
>   https://wiki.debian.org/DebianRepository/Format#Date.2C_Valid-Until
>
>   The idea being that 'guix pull' would fail if the repository hasn't
>   been touched after the specified interval end, causing the user notice
>   and take action.  The maximum interval provided by the repository
>   should probably be limited by a locally configured maximum delay the
>   user is willing to only see old data.

How would you communicate that validity period to clients though?  One
could use a HTTP header but I don’t think Git clients (libgit2 in this
case) pay attention to that.

[...]

> * Have a third party, or even decentralized system, monitoring service
>   where each client can compare the commit data they got from 'guix
>   pull' with what everyone else is seeing.  This provides global
>   consistency of what Guix machines are seeing for the Guix
>   repositories, similar to Certificate Transparency.  This protect
>   against targetted stale data attacks only, but that may be sufficient:
>   any non-targetted stale data attack is likely to be noticed by Guix
>   maintainers.

I think non-targeted stale data attacks (i.e., attacks on the primary
Git repo) would be detected by Guix committers promptly.  So in fact,
I’m not that concerned about this one.  And then there’s protection
about stale mirrors, too.

As for targeted attacks, where one would essentially trick a person into
talking to git.evil.com instead of git.sv.gnu.org and fetching a stale
repo from there, I don’t know.  The “reference state log” mechanism can
address that IIRC, but it requires modifications to Git clients and
servers.

Some sort of Commit Transparency log sounds interesting, but it also
raises the issue of what trust to put into that log (what to do when the
transparency log and the repo disagree?).

>   This would also protect against substitution attacks, although I'm not
>   sure if Guix protects against them by other means?  I'm thinking a
>   malicious savannah could send me core-updates instead of master, but
>   call it master to my machine, and I'll not notic that I got a
>   different branch instead.  Does 'guix authenticate' verify meta-data
>   such as git branch in a way where the server cannot fake this data?

‘guix git authenticate’ only checks the “authorization invariant”.

The article above also mentions “teleport attacks”, which are not
addressed per se.  There was a discussion with Maxime Devos describing
an attack whereby the attack would change ‘master’ to point to the
‘core-updates’ branch, which in practice could lead users to download
stale packages, as discussed in Section 6:


There’s no easy way to address that, but it’s also no very practical in
Guix.

Thanks for your feedback and for organizing the devroom!

Ludo’.

Re: configurable guile backtrace in builder

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Maxim Cournoyer  skribis:
>>
>>> Side topic: I wonder if (with some changes to the daemon -- perhaps in
>>> DerivationGoal::startBuilder) in nix/libstore/build.cc we could leak the
>>> COLUMNS variable to be able to control the Guile builder backtrace
>>> width.
>>
>> As a rule of thumb, I think we should keep the build environment
>> unchanged forever—no changes to the set of environment variables and
>> files/directories present in the build environment.
>>
>> It’s important because the whole reproducibile-by-construction approach
>> depends on that.
>
> I understand it can be risky to change anything on the builder side for
> reproducibility.

It’s not that it’s risky, it’s something we should never do; it’s crucial.

> Would you have an idea of the angle this problem should be approached
> from, where the goal is to have a configurable Guile backtrace width
> in the builder?

How about passing #:env-vars '(("COLUMNS" . "200")) to
‘gexp->derivation’ (in the build system), or adding a phase that sets
that environment variable?

HTH,
Ludo’.

Re: Google Summer of Code?

[Pjotr Prins]

I think we can add a few projects. Happy to co-mentor.

On Wed, Feb 08, 2023 at 10:03:06AM +0100, Ludovic Courtès wrote:
> Hello Guix!
> 
> Jose Marchesi applied to have GNU participate as an umbrella
> organization in GSoC:
> 
>   https://lists.gnu.org/archive/html/summer-of-code/2023-02/msg0.html
> 
> Participation in internship programs was discussed at the Guix Days and
> quite a few people were enthusiastic about resuming participation in
> these programs.
> 
> I think we could submit project ideas as Jose outlines in the message
> above, possibly starting by collecting them on a wiki page as we did in
> the past.  For reference, this is what we had in previous years:
> 
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2021
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2020
> 
> Who would like to coordinate that effort and/or offer to mentor a
> specific project?
> 
> (I am not offering to do any of these :-) but I’m happy to provide
> feedback or share my experience regarding mentoring.)
> 
> Ludo’.
> 

Re: Google Summer of Code?

[Jonathan Brielmaier]

On 08.02.23 10:45, Pjotr Prins wrote:

I think we can add a few projects. Happy to co-mentor.


I created a wiki page at libreplanet:
https://libreplanet.org/wiki/Group:Guix/GSoC-2023

I added a list of unique project ideas from 2018 to 2021, removing those
already done. Yeah, there are some done already :)

I think now we need to talk about which off them we wanna offer for 2023
and where we have a capable mentor. New project ideas are always welcome :)

Count me in as a co-mentor.

~Jonathan

Re: Google Summer of Code?

[pukkamustard]

Jonathan Brielmaier  writes:

> I created a wiki page at libreplanet:
> https://libreplanet.org/wiki/Group:Guix/GSoC-2023

Thanks!

I'd be happy to co-mentor a project on distributed substitutes with
ERIS and all that fun stuff.

I'll try and add some notes to the wiki page in the next few days.

-pukkamustard

Re: Google Summer of Code?

[Simon Tournier]

Hi,

On mer., 08 févr. 2023 at 10:03, Ludovic Courtès  wrote:

> Jose Marchesi applied to have GNU participate as an umbrella
> organization in GSoC:
>
>   https://lists.gnu.org/archive/html/summer-of-code/2023-02/msg0.html

The deadline for applying as our own* organization is over (February 7,
2023).  Therefore, if we want to be, maybe?, part of the GSoc this
summer 2023, our best option is to feed ideas as suggested. ;-)

> I think we could submit project ideas as Jose outlines in the message
> above, possibly starting by collecting them on a wiki page as we did in
> the past.  For reference, this is what we had in previous years:

>   https://libreplanet.org/wiki/Group:Guix/GSoC-2021
>   https://libreplanet.org/wiki/Group:Guix/GSoC-2020

Please provide any ideas, even ones which could look at first totally
crazy. :-)

Cheers,
simon

*run as our own organization: as GCC, GNU Radio, GNU Octave or GIMP.

https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-compiler-collection-gcc
https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-image-manipulation-program
https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-radio
https://summerofcode.withgoogle.com/archive/2022/organizations/gnu-octave

Re: configurable guile backtrace in builder

[Maxim Cournoyer]

Hello,

Ludovic Courtès  writes:

> Hi Maxim,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> Maxim Cournoyer  skribis:
>>>
 Side topic: I wonder if (with some changes to the daemon -- perhaps in
 DerivationGoal::startBuilder) in nix/libstore/build.cc we could leak the
 COLUMNS variable to be able to control the Guile builder backtrace
 width.
>>>
>>> As a rule of thumb, I think we should keep the build environment
>>> unchanged forever—no changes to the set of environment variables and
>>> files/directories present in the build environment.
>>>
>>> It’s important because the whole reproducibile-by-construction approach
>>> depends on that.
>>
>> I understand it can be risky to change anything on the builder side for
>> reproducibility.
>
> It’s not that it’s risky, it’s something we should never do; it’s crucial.

Okay.

>> Would you have an idea of the angle this problem should be approached
>> from, where the goal is to have a configurable Guile backtrace width
>> in the builder?
>
> How about passing #:env-vars '(("COLUMNS" . "200")) to
> ‘gexp->derivation’ (in the build system), or adding a phase that sets
> that environment variable?

That sounds like a reasonable solution to me!  It's pretty "fixed" while
I would have preferred a user-configurable value, but it's better than
the current situation, so I'd say let's go for it on core-updates!

-- 
Thanks,
Maxim

Re: Getting tree-sitter grammars in Guix

[Demis Balbach]

On 2023-02-06 18:25, Simon Tournier wrote:

> Hi,
>
> On sam., 04 févr. 2023 at 20:27, Demis Balbach  wrote:
>
>> My understanding is that I need to provide emacs with tree-sitter
>> support as an input for this to work, which I did, but it'll fail with
>>
>> --8<---cut here---start->8---
>> Debugger entered--Lisp error: (file-missing "Cannot open load file" "No such 
>> file or directory" "treesit")
>> --8<---cut here---end--->8---
>>
>> Maybe someone can help me here. I tried looking at other package
>> definitions, but I don't know if there are any emacs packages that
>> require tree-sitter packaged in Guix yet.
>
> Could you share your definition of Emacs variant allowing tree-sitter?
>
> Please note it is not clear for me if the tree-sitter parsers should be
> provided by Guix since 1. they are auto-generated and so it is against
> the effort to debootstrap and 2. they are often very large.
>
> Cheers,
> simon

Hello Simon,

as far as I understand emacs is already packaged with tree-sitter
support in Guix (I didn't know this when I wrote my last message).

Regarding packaging emacs packages that leverage tree-sitter, one just
has to provide the correct emacs version as an argument, like:

--8<---cut here---start->8---
;; ...
(arguments
`(#:emacs ,emacs-next-pgtk
 ;; ...
))
--8<---cut here---end--->8---

Thanks to Andrew Troping for showing me that.

-- 
Best regards / Mit freundlichen Grüßen,
Demis Balbach


signature.asc
Description: PGP signature