Re: EXWM

[Jan Nieuwenhuizen]

André A. Gomes writes:

> Jan Nieuwenhuizen  writes:
>
>> I just tried adding my ~/.exwm into my init.el and running a nested
>> emacs and now I get a GUI dialog:
>>
>> Replace existing window manager? Y/N
>>
>> Not great!  Not very suprisingly, the extra unnecessary initialization
>> /does/ hurt here.
>
> Isn't exwm doing precisely what it's supposed to do?  Isn't it fair that
> the newly spawned (nested) Emacs has the right to take control over the
> "older" Emacs?

Of course; that's my point exactly!  Emacs cannot know, and thus cannot
help but doing the annoying thing: throwing a dialogue.  That is what
this code

--8<---cut here---start->8---
(cond ((file-exists-p "~/.exwm") (load-file "~/.exwm"))
  ((not (featurep (quote exwm)))
   (require (quote exwm))
   (require (quote exwm-config))
   (exwm-config-default)
   (message (concat "exwm configuration not found. "
"Falling back to default configuration..."
--8<---cut here---end--->8---

helps to prevent in a very nice way.  Let's please keep it!

Greetings,
Janneke

-- 
Jan Nieuwenhuizen  | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com

Re: Tricking peer review

[Giovanni Biscuolo]

Hi Simon and Ludovic,

very interesting thread, thank you!

I think the "final" result of this discussion should be condensed in a
few (one?) additional paragraphs in the Contributing section of the Guix
manual

zimoun  writes:

[...]

>  - url-fetch: the attacker has to introduce the tarballs into SWH.
>There is not so much means, from my understanding: SWH ingests
>tarballs via loaders, for instance gnu.org or sources.json or
>debian.org etc. Therefore the attacker has to introduce the malicious
>code to these platforms.
>
>  - url-fetch without metadata (as your example), indeed, the reviewer
>could be abused; mitigated by the fact that “guix lint” spots the
>potential issue.
>
>  - url-fetch with metadata: the attacker have to also corrupt
>Diasarchive-DB.   Otherwise, the tarball returned by SWH will not
>match the checksum.
>
>  - svn-fetch, hg-fetch, cvs-fetch: no attack possible, yet.
>
>  - git-fetch: it is the *real* issue.  Because it is easy for the
>attacker to introduce malicious code into SWH (create a repo on
>GitHub, click Save, done).  Then submit a package using it as you
>did.  It is the same case as url-fetch without metadata but easier
>for the attacker.  It is mitigated by “guix lint”.

Well done Simon: AFAIU this is a complete analisys of the possible
"source" attacks, or is something missing?

> That’s said, if I am an attacker and I would like to corrupt Guix, then
> I would create a fake project mimicking a complex software.  For
> instance, Gmsh is a complex C++ scientific software.  The correct URL is
>  and the source at
> .  Then, as an attacker, I buy the
> domain say gmsh.org

or onelab.org, onehab.info and also set up a https://onehab.info web
site identical to the legitimate one just to trick people

> and put a malicious code there.  Last, I send for
> inclusion a package using this latter URL.  The reviewer would be
> abused.
> That’s why more eyes, less issues. :-)

I agree, but eyes should also be aware of this class of possible attacks

>> Also, just because a URL looks nice and is reachable doesn’t mean the
>> source is trustworthy either.  An attacker could submit a package for an
>> obscure piece of software that happens to be malware.  The difference
>> here is that the trick above would allow targeting a high-impact
>> package.
>
> I agree.

I also agree (obviously) and I think this kind of attack should also be
documented in the manual (if not already done)

[...]

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

[off-topic]

[Jonathan McHugh]

Hello,

I noticed an interesting report^1 on the holistic approach from Emacs and how 
its 'additive solutions' assist problem solving for researchers. Given Guix's 
emphasis on reproducible research I felt it worth sharing given overlapping 
concerns.

https://www.ingentaconnect.com/content/matthey/jmtr/pre-prints/content-jm_jmtr_johnsapr22
```
It is human nature to prefer additive problem solving even if removal may be 
the more efficient solution. This heuristic has wide ranging implications when 
dealing with science, innovation and complex problem solving. This is 
compounded when dealing with these issues at an institutional level. Additive 
solutions to workflows with extra software tools and proprietary digital 
solutions can impede work without offering any advantages in terms of FAIR data 
principles or productivity. The below Viewpoint highlights one possible 
workflow and the mentality underpinning it with an aim to incorporate FAIR 
data, improved productivity and longevity of written documents while improving 
workloads within industrial R&D. 
```


^1 via the blog Irreal


Jonathan McHugh
indieterminacy@libre.brussels

patches for new packages proper workflow (Re: Tricking peer review)

[Giovanni Biscuolo]

Hi,

zimoun  writes:

[...]

>> All in all, it’s probably not as worrisome as it first seems.  However,
>> it’s worth keeping in mind when reviewing a package.
>
> I agree with a minor comment.  From my opinion, not enough patches are
> going via guix-patches and are pushed directly.
>
> For instance, the «Commit policy» section says «For patches that just
> add a new package, and a simple one, it’s OK to commit, if you’re
> confident (which means you successfully built it in a chroot setup, and
> have done a reasonable copyright and license auditing).»
>
> And from my point of view, new packages should *always* go via
> guix-patches, wait 15 days, then push if no remark.  It lets the time
> for the community to chime in.  And if not, it just slows down for 2
> weeks.

I agree with Simon, the policy to add new packages should be changed as
he proposes.

Thanks! Giovanni

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

--with-source version not honored?

[Phil Beadling]

Hi all,

I'm using the following incantation:

guix build
--with-source=foobar@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64
<--with-source=gurobipy@9.5.0=/opt/thirdparty/gurobi/gurobi950_beta/linux64>
foobar


However the package build is failing with:

(copy-file "lib/libfoobar.so.9.0.1" "/gnu/store/gkawzac…")

In procedure copy-file: No such file or directory


That is the new version number 9.5.0 is not written to every place when
transforming the original package (version 9.0.1).  I think only the
package-version is updated, but the other package components are not then
regenerated, meaning that if they use the package-version as an input we
get a disjoint package.

In the example above I use version like so:






*(add-after 'install 'install-foobar-library
  (lambda* (#:key outputs #:allow-other-keys)
  (let* ((dir (string-append (assoc-ref outputs "out")

"/lib/python3.8/site-packages/foobar/"))
 (lib-to-install (string-append
"libfoobar.so." ,version))*

But ",version" is not updated, nor is it updated if I change this to call
(package-version foobar).


If I drop into Guile I can see this a bit more clearly by writing a
manifest - the code below gives exactly the same error however when the
package-version is displayed it correctly responds with 9.5.0.

Not sure if this should be considered a bug, or if there is a lazy way of
evaluating version so avoid the problem - I think it's unexpected from a
practicioners point of view as packages end up inconsistent.

I presume I can manually replace the arguments section of the package in
the manifest to workaround this - is there a standard way of doing this?

Any ideas or clarifications welcome!

Cheers,
Phil.
















*(use-modules (guix transformations) (guix packages))(define
transform  ;; The package transformation procedure.
(options->transformation   '((with-source .
"gurobipy@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64"(define
my-package (transform (specification->package "foobar")))(display
(package-version my-package)) ;; this will display version
9.5.0(newline)(packages->manifest (list my-package)) ;; building this will
fail because copy-file still looks for 9.0.1*

Re: Tricking peer review

[zimoun]

Hi,

On Wed, 20 Oct 2021 at 10:22, Giovanni Biscuolo  wrote:

> I think the "final" result of this discussion should be condensed in a
> few (one?) additional paragraphs in the Contributing section of the Guix
> manual

Run “guix lint” is already listed.  What do you have in mind about more
additions?


> Well done Simon: AFAIU this is a complete analisys of the possible
> "source" attacks, or is something missing?

To my knowledge, yes it is exhaustive with the current situation about
tricking the content-addressed system.

On the top of that, it is addressed by hash functions; it is thus
vulnerable to preimage attack of such hash functions.  SWH uses SHA-1 to
address and I do not know how they address potential collisions.

For instance, the cost for SHA-1 [1] is still really expensive.  Well,
for interested reader, one can read the discussion here [2].  SHA-1 is
2^160 (~10^48.2) and compare to 10^50 which is the estimated number of
atoms in Earth.  Speaking about content-addressability, SHA-1 seems
fine.  We are speaking about content-addressability not about using
SHA-1 as hash function for security, IMHO.  It is the same situation as
Git, for instance.

The surface of attack is very low because:

 a) SWH is an archive and not a forge,
 b) a chosen-prefix attack [3] could no work if review is correctly done;
which means run “guix lint”,
 c) an attacker has to trick the checksum (SHA-256) and the address
(SHA-1); at various locations: Guix history (now signed), SWH,
 Disarchive-DB.

1: 
2: 
3: 

>>> Also, just because a URL looks nice and is reachable doesn’t mean the
>>> source is trustworthy either.  An attacker could submit a package for an
>>> obscure piece of software that happens to be malware.  The difference
>>> here is that the trick above would allow targeting a high-impact
>>> package.
>>
>> I agree.
>
> I also agree (obviously) and I think this kind of attack should also be
> documented in the manual (if not already done)

Well, nothing new here, IMHO.  A distribution relies on content, i.e.,
any distribution points to that content.  Whatever the nature of the
pointing arrow (URL, Git commit, hash, etc.), the pointed material must
be carefully checked at package time; as explained by «Submitting
Patches» [4]. :-) That’s why I am advocating [5] that:

 new packages should *always* go via guix-patches, wait 15 days,
then push if no remark.  It lets the time for the community to
chime in.  And if not, it just slows down for 2 weeks.


4: 
5: 

Cheers,
simon

Disarchive and SHA

[zimoun]

Hi,

Trying to investigate why, for instance,

--8<---cut here---start->8---
$ guix lint -c archival zabbix-agentd
gnu/packages/monitoring.scm:167:5: zabbix-agentd@5.2.6: Disarchive entry refers 
to non-existent SWH directory 'e664cd5e820df2a194a5c6a64f12161480331b4b'
--8<---cut here---end--->8---

I notice something annoying.  For representing SHA-256, Guix uses
’nix-base32’ and Disarchive uses ’base16’.

Therefore, from the source,

--8<---cut here---start->8---
(define-public zabbix-agentd
  (package
(name "zabbix-agentd")
(version "5.2.6")
(source
 (origin
   (method url-fetch)
   (uri (string-append
 "https://cdn.zabbix.com/zabbix/sources/stable/";
 (version-major+minor version) "/zabbix-" version ".tar.gz"))
   (sha256
(base32 "100n1rv7r4pqagxxifzpcza5bhrr2fklzx7gndxwiyq4597p1jvn"
--8<---cut here---end--->8---

it does not match the URL:



and instead, one has to convert to ’base16’.  I am not aware of any tool
to ease this transformation.  Maybe, we could add an option to “guix
hash”.  WDYT?


Using ’base16’, the URL matches and the file is downloaded.  Neat!





Along the process, I also notice,

--8<---cut here---start->8---
$ guix download 
https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz

Starting download of /tmp/guix-file.rcYxyF
>From https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz...
download failed 
"https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz"; 404 "Not 
Found"

Starting download of /tmp/guix-file.rcYxyF
>From 
>https://web.archive.org/web/20211020115955/https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz...
following redirection to 
`https://web.archive.org/web/20210410075108/https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz'...
 …2.6.tar.gz350KiB/s 
00:57 | 19.6MiB transferred
/gnu/store/3w8mp25gyrkq3dngaw27kvqaggrx9qp0-zabbix-5.2.6.tar.gz
100n1rv7r4pqagxxifzpcza5bhrr2fklzx7gndxwiyq4597p1jvn
--8<---cut here---end--->8---

And this fallback is not done by the file ’sources.json’.

--8<---cut here---start->8---
$ wget https://guix.gnu.org/sources.json
$ cat sources.json | jq | grep zabbix
  "git_url": "https://github.com/lukecyca/pyzabbix";,
"https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz";
  "git_url": "https://github.com/unioslo/zabbix-cli";,
"https://cdn.zabbix.com/zabbix/sources/stable/5.2/zabbix-5.2.6.tar.gz";
--8<---cut here---end--->8---

That’s why «Disarchive entry refers to non-existent SWH directory».


Help welcome for improving this ’sources.json’. :-)  Especially, turning
the current way using the website builder into derivation-style usable
by the CI.


Cheers,
simon

Re: --with-source version not honored?

[Julien Lepiller]

I think your incantation is incorrect: you build foobar@9.0.1, and you replace 
the source of foobar@9.5.0 only.

For the rest of your question, I think there is actually no way to fix that: 
when you use ",version", it gets evaluated before you can import the package. 
Maybe (package-version this-package) would work?

Le 20 octobre 2021 05:18:02 GMT-04:00, Phil Beadling  a 
écrit :
>Hi all,
>
>I'm using the following incantation:
>
>guix build
>--with-source=foobar@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64
><--with-source=gurobipy@9.5.0=/opt/thirdparty/gurobi/gurobi950_beta/linux64>
>foobar
>
>
>However the package build is failing with:
>
>(copy-file "lib/libfoobar.so.9.0.1" "/gnu/store/gkawzac…")
>
>In procedure copy-file: No such file or directory
>
>
>That is the new version number 9.5.0 is not written to every place when
>transforming the original package (version 9.0.1).  I think only the
>package-version is updated, but the other package components are not then
>regenerated, meaning that if they use the package-version as an input we
>get a disjoint package.
>
>In the example above I use version like so:
>
>
>
>
>
>
>*(add-after 'install 'install-foobar-library
>  (lambda* (#:key outputs #:allow-other-keys)
>  (let* ((dir (string-append (assoc-ref outputs "out")
>
>"/lib/python3.8/site-packages/foobar/"))
> (lib-to-install (string-append
>"libfoobar.so." ,version))*
>
>But ",version" is not updated, nor is it updated if I change this to call
>(package-version foobar).
>
>
>If I drop into Guile I can see this a bit more clearly by writing a
>manifest - the code below gives exactly the same error however when the
>package-version is displayed it correctly responds with 9.5.0.
>
>Not sure if this should be considered a bug, or if there is a lazy way of
>evaluating version so avoid the problem - I think it's unexpected from a
>practicioners point of view as packages end up inconsistent.
>
>I presume I can manually replace the arguments section of the package in
>the manifest to workaround this - is there a standard way of doing this?
>
>Any ideas or clarifications welcome!
>
>Cheers,
>Phil.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>*(use-modules (guix transformations) (guix packages))(define
>transform  ;; The package transformation procedure.
>(options->transformation   '((with-source .
>"gurobipy@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64"(define
>my-package (transform (specification->package "foobar")))(display
>(package-version my-package)) ;; this will display version
>9.5.0(newline)(packages->manifest (list my-package)) ;; building this will
>fail because copy-file still looks for 9.0.1*

Re: --with-source version not honored?

[zimoun]

Hi,

On Wed, 20 Oct 2021 at 13:27, Julien Lepiller  wrote:
>
> I think your incantation is incorrect: you build foobar@9.0.1, and you 
> replace the source of foobar@9.5.0 only.

It reminds me this thread:




All the best,
simon

Re: [off-topic]

[zimoun]

Hi,

For French-speaker, here Emacs+Org+Guix at the previous Guix wrokshop:




I also recommend this MOOC as a starting point for Reproducible
notebook using Org-mode (I do not remember if it available for
non-French speaker):



A part using Guix should be added later, for the next sessions of this MOOC. :-)


Cheers,
simon

Strange behavior with package input rewriting

[goshib]

Hello, everyone.

I'm new to Guix and Guile and recently started to tinker with package variants.
But I have bumped into some strange guix behavior.  I'm not sure, if this is
a bug or my misconfiguration.

Everything started after I had built the full chain of rust compilers from the
very beginning (mrust) to the latest version 1.52.  It took me several days or
weeks.  To save disk space, I removed all the previous versions.  But then
discovered, that packages can depend on previous rust versions.  To avoid this
heavy recompilation, I decided, that this is the case for `--with-input=`
package input rewriting.

So, strange behavior #1:

guix build jami-gnome --with-input=rust=rust

seems to do what I want, but

guix install jami-gnome --with-input=rust=rust

tries to build all rust packages up to rust@1.45.2 anyway.  Generally speaking,
all `guix package` commands do not comply with my `--with-input=rust=rust` or
`--with-input=rust=rust@1.52` argument.

So, I cannot install this jami version directly, but can build it and then
install its /gnu/store/... output.  But that breaks my package upgrades -- guix
will try to reinstall the standand jami-gnome.  So I decided to write this
package input rewriting in guile, first in a package manifest, then in my own
package module.  This is where I stuck.

So, I have an exported GUIX_PACKAGE_PATH environment variable and some working
modules with package variants: bc with readline support (copied from some issue
on issues.guix.info) and glibc-utf8-locales with a modified locales list.  I 
write
`(package (inherit ) ...` and then just modify the needed package
parameters.  `guix package -A` and `guix show` show both the original and my
modified versions, `guix build` and `guix install` work and use the modified
versions.

But when I tried to use the construct

(package
  (inherit ((options->transformation '((with-input . "rust=rust@1.52")))
jami-gnome)))

from Guix documentation, it didn't work.

It seems that `guix package -A jami-gnome` shows both the original and my
modified versions, but guix show/build/install doesn't see the modified version
and tries to build the full rust chain.

Then I discovered, that using package-input-rewriting instead of
options->transformation works.  This also works:

(package-input-rewriting/spec `(("rust" . ,(const rust-1.52

Looking in guix sources I found that procedure find-packages-by-name doesn't
work. So, poking around it, I created a short example module, that works:

(define-module (bc)
  #:use-module (guix packages)
  #:use-module (gnu packages)
  #:use-module (gnu packages algebra))

(define-public bc2
  (package
(inherit bc)
(version "2.test")))

(define var (find-packages-by-name "git"))

But if you put the last line before the bc2 package definition, it stops working
normally: `guix package -A '^bc$'` shows both versions, but all other guix
commands do not see the "2.test" version.

So the question: is this a guix bug, or am I writing wrong in Guile?


-- 
Sent with https://mailfence.com  
Secure and private email

Re: Disarchive and SHA

[zimoun]

Hi,

On Wed, 20 Oct 2021 at 12:23, zimoun  wrote:

> --8<---cut here---start->8---
> (define-public zabbix-agentd
[...]
>(sha256
> (base32 "100n1rv7r4pqagxxifzpcza5bhrr2fklzx7gndxwiyq4597p1jvn"
> --8<---cut here---end--->8---
>
> it does not match the URL:
>
> 
>
> and instead, one has to convert to ’base16’.  I am not aware of any tool
> to ease this transformation.  Maybe, we could add an option to “guix
> hash”.  WDYT?

For the interested reader, the trick is to use...

--8<---cut here---start->8---
$ guix hash -f base16 $(guix build zabbix-agentd -S)
76cb704f2a04fbc87bb3eff44fa71339c355d467f7bbd8fb53f8927c760e1680
--8<---cut here---end--->8---

> Using ’base16’, the URL matches and the file is downloaded.  Neat!
>
> 

...but it must download.  Instead, I propose the patch#51307 which
convert without downloading.  WDYT?

1: 


Cheers,
simon

Re: --with-source version not honored?

[Phil]

Thanks for the reply.

Julien Lepiller writes:

> evaluated before you can import the package. Maybe (package-version 
> this-package) would work?

Yes! (package-version this-package) worked perfectly - thanks for your help.

Re: --with-source version not honored?

[Phil]

Hi

zimoun writes:

> It reminds me this thread:
>
> 

Thanks this is an interesting thread - I stumbled upon a quirk trying to
find the right combination of switches.

I found that if I do this (which I think is bad):

guix environment --with-source=foobar@9.5.0=/path/to/package
some-package-that-depends-on-foobar --ad-hoc foobar

This gives me the warning that with-source will have no effect on
some-package-that-depends-on-foobar, but that's not strictly true here.

In this case the depending package's dependencies are installed into the
environment including the original version of foobar (9.0.1) first, but this
is then overwritten by foobar@9.0.5 - I can see files from
both packages under the site-packages for foobar.

Weirdly this is almost what I was trying to do:
"Install some-package-that-depends-on-foobar, but rebuilt with the version of
foobar from with-source."

However the reason it works is probably not intended behavior.

I couldn't work out an incantation that provided this facility properly
- my best guess was:

guix environment --with-source=foobar@9.5.0=/path/to/package
--with-inputs=foobar=foobar@9.5.0 some-package-that-depends-on-foobar

Which returns that it can't find foobar@9.5.0.

I figure at this point I might have more luck if I drop into Guile to do
this, but it's always a win when I can do it as a one-liner in shell.

Any ideas if I can create a new package with --with-source and then
substitute it in the same command for an input of another package? 

Preservation of Guix Report

[Timothy Sample]

Hi everyone!

Early this summer I did a bunch of work trying to figure out which Guix
sources are preserved by the SWH archive.  I’m finally ready to share
some preliminary results!

https://ngyro.com/pog-reports/2021-10-20/

This report is already quite outdated, though.  It only covers commits
up to the end of May, and sometime in June is when the sources were
checked against the SWH archive.  I’m sharing it now to avoid any
further delays.

What’s cool is that the report is automated.  Next on my list is to
update the database and generate a new report.  Then, we can compare the
results and see if we are improving.  (My read on the results so far is
that improving “sources.json” will yield big improvements, but we might
not be able to get to that before the next report.)

The report itself only provides a very high level overview.  If you want
to check on specifics, you will have to download the database.  There’s
a link at the bottom of the report as well as a link to a detailed
schema definition.  Anyone interested in making some sense of the 5,043
known missing sources is encouraged to look there.  However, I can say
from my own investigation that a lot of them are kinda boring.  For
instance, 3,435 are from crates.io, CRAN, Hackage, Bioconductor, and
CPAN:

select count(*)
from fods
join fod_references using (fod_id)
where not is_in_swh
and (reference like '%crates.io%' or
 reference like '%/cran/%' or
 reference like '%hackage%' or
 reference like '%/bioconductor.%' or
 reference like '%/cpan/%');
=> 3435

It’s surprising to me that SWH is not already getting these from
“sources.json”.  I picked an arbitrary one, “rust-quote-0.6”, and it’s
simply not in “sources.json”.  On the other hand, I bet SWH would like a
crates.io (and CRAN, etc.) loader, too.

One other more interesting approach might be to check Git sources:

select count(*)
from fods
join fod_references using (fod_id)
where not is_in_swh
and reference like '(git-reference%';
=> 336

There are fewer, but they might be more interesting.  Just be sure to
check that they haven’t made it into the SWH archive since June.  For
instance, I just checked “asciidoc@9.1.0” and learned that the database
has “NOT is_in_swh”, but it is now in the SWH archive.  So, caveat
emptor, I guess.  Maybe it would be wise to wait for a more recent
report before diving in.

One other way to help would be to suggest improvements to the report.  I
don’t want to fiddle with it too much, but if there is some simple graph
or table or list that should be there, I’m happy to give it a go.


-- Tim

Public guix offload server

[Arun Isaac]

Hi Guix,

This is a follow-up to the "Incentives for review" thread.

I think it would be nice to have a public/semi-public access `guix
offload' server. My own machine is relatively slow and has a spinning
disk. I can't really review "big patches" (in the sense of build time)
without ruining a few days of my life. So, I usually refrain from
reviewing patches to packages with a lot of dependents. And, I don't
participate in world-rebuilding tasks such as merging core-updates. This
problem is becoming worse as Guix grows larger and the dependencies
become more complex. Perhaps, if we had a public `guix offload' server
to which I could offload cumbersome builds, I might feel more encouraged
to review tough patches.

If security is a problem with a public access guix offload server, we
could make it semi-public and available at least to people with commit
access. Currently, guix offload requires mutual trust between the master
and the build machines. If we could make the trust only one-way,
security might be less of an issue.

WDYT? How does everyone else handle big builds? Do you have access to
powerful workstations?

Regards,
Arun


signature.asc
Description: PGP signature

Re: Incentives for review

[Thiago Jung Bauermann]

Hello,

Em terça-feira, 19 de outubro de 2021, às 12:41:23 -03, Ludovic Courtès 
escreveu:
> zimoun  skribis:
> > On Tue, 19 Oct 2021 at 14:56, Ludovic Courtès 
 wrote:
> [...]
> 
> I would like to see us committers do more review work.  But I also view
> things from a different angle: everyone contributes in their own way,
> and each contribution is a gift.  We can insist on community
> expectations (reviewing other people’s work), but we should also welcome
> contributions as they come.

Thank you for viewing it from that angle. On a personal note, I’m aware 
that my ratio of patches reviewed / patches posted approaches zero and this 
makes me a bit uncomfortable every time I type `git send-email`.

Sometimes I try to review patches, but it’s not a very productive endeavour 
for a few reasons:

1. In many cases, I don’t see anything wrong with the patch I’m looking at. 
In those cases I could reply saying so, but I refrain from doing that 
because if such message comes from someone who doesn’t have much experience 
in the part of Guix that the patch touches (which is almost always the case 
for me when reviewing patches), then how much values does that really add?

2. Going through the guix-patches mailing list looking for submissions that 
touch the few areas of Guix where I have at least some experience. I don’t 
think I found an effective method yet (in part the problem is on my side 
because the search function of the email client I use isn’t very reliable).

> There’s a balance to be found between no formal commitment on behalf of
> committers, and a strict and codified commitment similar to what is
> required for participation in the distros list¹.
> 
> A good middle ground may be to provide incentives for review.  How?  I’m
> not sure exactly, but first by making it clear that review is makes the
> project move forward and is invaluable.  You once proposed having
> ‘Reviewed-By’ tags to acknowledge non-committer reviews, and I think
> that would be one step in that direction.

I like the ‘Reviewed-by’ idea and I agree that it provides a tangible 
incentive. A ‘Tested-by:’ tag would have the same effect as well, as 
suggested by simon.

> Perhaps there are other things we could do?

One thing that would help me would be some way to “subscribe” to changes in 
certain areas of Guix. That way, when a patch is submitted which touches 
those areas I would be automatically copied on the emails that go to the 
guix-patches mailing list. “areas of Guix” could be defined by paths in the 
repo, guile modules or regexps matching package names, for example.

-- 
Thanks,
Thiago

Re: Public guix offload server

[Tobias Geerinckx-Rice]

Hi Arun,

Arun Isaac 写道：
If security is a problem with a public access guix offload 
server, we
could make it semi-public and available at least to people with 
commit

access.


Giving access only to people with commit access is a given, but 
any shared offload server is a huge shared security risk.


Guix is not content-addressed.  Any [compromised] user can upload 
arbitrary malicious binaries with store hashes identical to the 
legitimate build.  These malicious binaries can then be downloaded 
by other clients, which presumably all have commit access.


Now the attacker almost certainly has covert access to one or more 
user accounts that can push signed commits to Guix upstream.



Currently, guix offload requires mutual trust between the master
and the build machines. If we could make the trust only one-way,
security might be less of an issue.


It might!  It's easy to imagine a second, less powerful offload 
protocol where clients can submit only derivations to be built by 
the remote daemon, plus fixed-output derivations.  None of the 
‘let me send the entire binary toolchain so you don't have to 
build it from scratch’ of the current protocol.  This at least 
removes their control over the source hash.


At that point, one might consider dropping SSH account-based 
access in favour of a minimal job submission API, and just return 
the results through guix publish or so…?  OTOH, that's yet another 
code path.


WDYT? How does everyone else handle big builds? Do you have 
access to

powerful workstations?


By waiting, and planning.  I'm lucky to have a ridiculously 
overpowered ThinkPad for its age and a newer headless tower at 
home that can run builds 24/7, but nothing close to a ‘powerful 
workstation’ by industry standards.


Zzz,

T G-R


signature.asc
Description: PGP signature

Re: Public guix offload server

[Leo Famulari]

On Wed, Oct 20, 2021 at 11:06:05PM +0200, Tobias Geerinckx-Rice wrote:
> Guix is not content-addressed.  Any [compromised] user can upload arbitrary
> malicious binaries with store hashes identical to the legitimate build.
> These malicious binaries can then be downloaded by other clients, which
> presumably all have commit access.

Interesting... I'm not at all familiar with how `guix offload` works,
because I've never used it. But it's surprising to me that this would be
possible. Although after one minute of thought, I'm not sure why it
wouldn't be.

However, the Guix security model trusts committers implicitly. So, if
the committers' shared offload server had proper access control, one
might consider it "good enough" in terms of security. Although the
possibility of spreading malicious binaries is much scarier than what
could be achieved by committing to guix.git, because of the relative
lack of transparency.


signature.asc
Description: PGP signature

Re: Public guix offload server

[Leo Famulari]

On Thu, Oct 21, 2021 at 02:23:49AM +0530, Arun Isaac wrote:
> WDYT? How does everyone else handle big builds? Do you have access to
> powerful workstations?

For my first several years with Guix... I handled big builds patience
and care.

I could have spent a small amount of money on powerful yet ephemeral
cloud computing.

Now I have access to a very powerful system on which I can test builds.

I agree that the Guix project should offer some powerful compute
resources to Guix developers. Efficiency is important for staying
motivated.


signature.asc
Description: PGP signature

Re: Tricking peer review

[Leo Famulari]

On Tue, Oct 19, 2021 at 10:39:12AM +0200, zimoun wrote:
> Drifting from the initial comment.  One could name “tragic” commits are
> commits which break “guix pull”.  It is rare these days but there are
> some reachable ones via “guix time-machine”.

That's a good point. Is it a good idea to teach Guix to help (not force)
users to avoid these commits?

Re: Tricking peer review

[Leo Famulari]

On Fri, Oct 15, 2021 at 08:54:09PM +0200, Ludovic Courtès wrote:
> The trick is easy: we give a URL that’s actually 404, with the hash of a
> file that can be found on Software Heritage (in this case, that of
> ‘grep-3.4.tar.xz’).  When downloading the source, the automatic
> content-addressed fallback kicks in, and voilà:
[...]
> Thoughts?

It's a real risk... another illustration that our security model trusts
committers implicitly (not saying that's a bad thing or even avoidable).

In years past I mentioned a similar technique but based on using
old/vulnerable versions of security-critical packages like OpenSSL. The
same approach would have worked since we started using Nix's
content-addressed mirror.

> It’s nothing new, it’s what I do when I want to test the download
> fallbacks (see also ‘GUIX_DOWNLOAD_FALLBACK_TEST’ in commit
> c4a7aa82e25503133a1bd33148d17968c899a5f5).  Still, I wonder if it could
> somehow be abused to have malicious packages pass review.

Nice feature! Sorry if this was already suggested, but is it possible to
create an argument to this variable that disallows use of the fallback
mechanisms? I would certainly use that while reviewing and testing my
own patches.

Re: Preservation of Guix Report

[Timothy Sample]

Hi again,

Rereading this a few hours later, I found an error.

Timothy Sample  writes:

> It’s surprising to me that SWH is not already getting these from
> “sources.json”.  I picked an arbitrary one, “rust-quote-0.6”, and it’s
> simply not in “sources.json”.

It is in fact there!  I made a mistake while grepping.

In the database, there’s “rust-quote-0.6@0.6.12” and
“rust-quote-0.6@0.6.13”.  The SWH archive has version 0.6.13, but not
0.6.12.  Looking back, 0.6.13 was released in July 2019, so maybe 0.6.12
predates “sources.json”?

AFAIK, we have no way of getting 0.6.12 into the SWH archive.  There’s
been some talk of making historical “sources.json” files  I imagine
this is one of many little things to work out.


-- Tim