bug#57611: [PATCH] Addressing bug#57611 by updating rust-wayland-client and rust-wayland-scanner dependencies

[Ben Van Sleen]

Hi,

This is my first patch to Guix (and my first time submitting a patch by
mailing list), so I'd love whatever feedback y'all have to offer!

Trying to address the alacritty build issue. As of now, alacritty won't
build because rust-wayland-scanner can't be built. After chasing many
dependencies, rust-parking-lot-core now requires rust-windows-sys-0.36.
rust-windows-sys-0.28 currently exists in the repo, so I've added packages
to bump the versions to 0.36.

After applying these patches, Alacritty now builds.

Best,
Ben Van Sleen

>From 682b335058c6dff1ea48165762ec8bbc0e469803 Mon Sep 17 00:00:00 2001
From: Ben Van Sleen 
Date: Wed, 7 Sep 2022 16:32:00 -0500
Subject: [PATCH 1/4] rust-windows-sys-0.36: Added package (updating existing
 package from 0.28 -> 0.36). Also added definitions for dependencies
 rust-windows-*-0.36

---
 gnu/packages/crates-io.scm | 86 ++
 1 file changed, 86 insertions(+)

diff --git a/gnu/packages/crates-io.scm b/gnu/packages/crates-io.scm
index a03f02e868..a9d8bd5669 100644
--- a/gnu/packages/crates-io.scm
+++ b/gnu/packages/crates-io.scm
@@ -74075,6 +74075,19 @@ (define-public rust-windows-x86-64-msvc-0.32
 crate.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-x86-64-msvc-0.36
+  (package
+(inherit rust-windows-x86-64-msvc-0.32)
+(name "rust-windows-x86-64-msvc")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows_x86_64_msvc" version))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+
 "103n3xijm5vr7qxr1dps202ckfnv7njjnnfqmchg8gl5ii5cl4f8"))
+
 (define-public rust-windows-x86-64-gnu-0.28
   (package
 (name "rust-windows-x86-64-gnu")
@@ -74114,6 +74127,19 @@ (define-public rust-windows-x86-64-gnu-0.32
 crate.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-x86-64-gnu-0.36
+  (package
+(inherit rust-windows-x86-64-gnu-0.32)
+(name "rust-windows-x86-64-gnu")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows_x86_64_gnu" version))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+
 "1qfrck3jnihymfrd01s8260d4snql8ks2p8yaabipi3nhwdigkad"))
+
 (define-public rust-windows-i686-msvc-0.28
   (package
 (name "rust-windows-i686-msvc")
@@ -74153,6 +74179,19 @@ (define-public rust-windows-i686-msvc-0.32
 crate.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-i686-msvc-0.36
+  (package
+(inherit rust-windows-i686-msvc-0.32)
+(name "rust-windows-i686-msvc")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows_i686_msvc" version))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+
 "097h2a7wig04wbmpi3rz1akdy4s8gslj5szsx8g2v0dj91qr3rz2"))
+
 (define-public rust-windows-i686-gnu-0.28
   (package
 (name "rust-windows-i686-gnu")
@@ -74192,6 +74231,19 @@ (define-public rust-windows-i686-gnu-0.32
 crate.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-i686-gnu-0.36
+  (package
+(inherit rust-windows-i686-gnu-0.32)
+(name "rust-windows-i686-gnu")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows_i686_gnu" version))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+
 "1dm3svxfzamrv6kklyda9c3qylgwn5nwdps6p0kc9x6s077nq3hq"))
+
 (define-public rust-windows-aarch64-msvc-0.28
   (package
 (name "rust-windows-aarch64-msvc")
@@ -74231,6 +74283,19 @@ (define-public rust-windows-aarch64-msvc-0.32
 crate.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-aarch64-msvc-0.36
+  (package
+(inherit rust-windows-aarch64-msvc-0.32)
+(name "rust-windows-aarch64-msvc")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows_aarch64_msvc" version))
+  (file-name (string-append name "-" version ".tar.gz"))
+  (sha256
+   (base32
+
 "0ixaxs2c37ll2smprzh0xq5p238zn8ylzb3lk1zddqmd77yw7f4v"))
+
 (define-public rust-windows-implement-0.32
   (package
 (name "rust-windows-implement")
@@ -74282,6 +74347,27 @@ (define-public rust-windows-sys-0.28
 if they were just another Rust module.")
 (license (list license:expat license:asl2.0

+(define-public rust-windows-sys-0.36
+  (package
+(inherit rust-windows-sys-0.28)
+(name "rust-windows-sys")
+(version "0.36.1")
+(source (origin
+  (method url-fetch)
+  (uri (crate-uri "windows-sys" version))
+  

bug#57559: guix pull fails on http status code 503

[Maxime Devos]

On 06-09-2022 15:09, zimoun wrote:

The initial report by André is about:

--8<---cut here---start->8---
$ guix pull
Updating channel 'nonguix' from Git repository at 
'https://gitlab.com/nonguix/nonguix'...
guix pull: error: Git error: unexpected http status code: 503
--8<---cut here---end--->8---

So the situation is more likely: Guix from Savannah is reachable and
guix-foo is not.

For sure, we can discuss the case when Guix is unavailable.  However,
the 'guix channel is special; see all conditionals using ’guix-channel?’.

Well, %default-guix-channel is somehow a corner use-case when the
regular use-case seems about a failure of additional channels.


The ‘Guix is unavailable’ was just a simple example. For the example, 
you can replace it, with, say nonguix. Automatically removing the 
additional channels upon 503 is undesirable I'd think, though the error 
messages will be different.


Greetings,
Maixme.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57653: pypy build fails due to a readelf error in validate-runpath

[Maxim Cournoyer]

Hello,

The pypy build fails like so:

--8<---cut here---start->8---
phase `strip' succeeded after 0.2 seconds
starting phase `validate-runpath'
validating RUNPATH of 4 binaries in 
"/gnu/store/qdypiywzkz71rayp9h2fipgj4cjksrg9-pypy-7.3.5/bin"...
/gnu/store/qdypiywzkz71rayp9h2fipgj4cjksrg9-pypy-7.3.5/bin/pypy3.debug: error: 
offset + size of segment 5 (type 1) exceeds total size
error: in phase 'validate-runpath': uncaught exception:
misc-error #f "RUNPATH validation failed" () #f 
phase `validate-runpath' failed after 0.0 seconds
Backtrace:
   8 (primitive-load "/gnu/store/6lmwh43qn67hc6r9nppg45m4ghk…")
In guix/build/gnu-build-system.scm:
906:2  7 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  5 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  4 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   927:23  3 (_)
   568:10  2 (validate-runpath #:validate-runpath? _ # _ #:outputs _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
RUNPATH validation failed
builder for `/gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv' failed 
with exit code 1
@ build-failed /gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv - 1 
builder for `/gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv' failed 
with exit code 1
derivation '/gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv' 
offloaded to 'localhost' failed: build of 
`/gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv' failed
build of /gnu/store/vy5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv failed
View build log at 
'/var/log/guix/drvs/vy/5d4324p733zsp9n56rh084rk8z957i-pypy-7.3.5.drv'.
--8<---cut here---end--->8---

Thanks,

Maxim

bug#57611: rust-once-cell (alacritty dependency) build failure

[Maxime Devos]

On 07-09-2022 01:15, Ben Van Sleen wrote:

Subject:
bug#57611: rust-once-cell (alacritty dependency) build failure
From:
Ben Van Sleen 
Date:
07-09-2022 01:15

To:
57...@debbugs.gnu.org


rust-once-cell-1 can't be built because it now depends on 
rust-parking-lot-core-0.9. This can't be built because it now requires 
rust-windows-sys-0.36 according to the crates page 
(https://crates.io/crates/parking_lot_core/0.9.3/dependencies). This 
package definition can be found in the guix channel that Must Not Be 
Named (right next to firefox), and is not present in the main guix repo.


I would guess the reasoning behind this is that rust-windows-sys 
requires some kind of nonfree code in its dependencies (perhaps 
rust-windows-aarch64-msvc-0.36?).
AFAICT it is free, though whoever maintains that package forgot to 
include a copy of the license text.
If I'm wrong about this and the package does meet the Guix repo 
standards, then the alacritty problem can be fixed by incorporating 
the rust-windows-sys-0.36 package definition into (gnu packages 
crates-io).


Another solution would be to remove the dependency rust-windows-sys from 
rust-parking-lot-core-0.9 by patching the Cargo.toml appropriately (this 
dependency is only required for compiling to Windows targets).


Greetings,
MAxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57436: Running ./configure from `guix shell -D guix --pure` errors

[Katherine Cox-Buday]

On Mon, Aug 29, 2022 at 1:29 PM zimoun  wrote:

> Do you mean update the «Building from Git» section?

Yes this is what I mean.

bug#57593: Racket 8.6 is not reproducible

[Philip McGrath]

Hi,

On Mon, Sep 5, 2022, at 6:04 AM, Ludovic Courtès wrote:
> Hey,
>
> Just noticed that Racket does not build in a reproducible fashion:
>
> --8<---cut here---start->8---
> $ guix describe
> Generation 227  Sep 04 2022 23:39:52(current)
>   guix aae98c2
> repository URL: https://git.savannah.gnu.org/git/guix.git
> branch: master
> commit: aae98c297214f87eb45302863adb021078c41a6f
> $ guix challenge racket | head -40
> /gnu/store/av255rh362283i1zaiq9rz4rpli69j59-racket-8.6 contents differ:
>   local hash: 1w4dnkvpbbrgfasyq8x1cbqw58jzqsny17ms5l1fb1h6iid38bs1
>   
> https://ci.guix.gnu.org/nar/lzip/av255rh362283i1zaiq9rz4rpli69j59-racket-8.6: 
> 1lnxklizpnc599w7n2svb1jaw595wranm9aagd2928fcbiaavbr6
>   differing files:
> /lib/racket/pkgs/2d-doc/scribblings/compiled/2d_scrbl.dep
> /lib/racket/pkgs/2d-doc/scribblings/compiled/2d_scrbl.zo

Unfortunately, this is a known issue upstream.

One part of the problem is the way that Chez Scheme uses "type 4" (random) 
UUIDs to implement 'gensym'. There's some upstream discussion at 
, including an idea from me 
about "type 5" UUIDs as part of a possible solution.

That may well be the only issue with the core compiler for Racket CS. I know 
effort has been taken to make Racket's front-end deterministic, and Kent Dybvig 
says that:

> Chez Scheme compiles are reproducible modulo the globally unique
> names of generated symbols (gensyms), assuming macros don't do
> things like introduce time stamps or random expressions into their output.
> Because of differences in gensym names, the files produced by multiple
> runs are not byte-by-byte identical but should compare equal via
> the system primitive $fasl-file-equal? See, for example, the use
> of $fasl-file-equal? in the s/Mf-base checkboot target.

In the output you sent, the ".zo" files contain Chez machine code with a 
Racket-specific wrapper, and the ".dep" files contain hashes of dependencies 
(so they differ when the ".zo" files they track differ).

Debian reports at 
,
 discussing Racket 8.2+dfsg1-2:

> Build path captured in html documentation. docindex.sqlite
> contains content in arbitrary order. strings in binaries in
> arbitrary order.

Those issues don't appear to affect Guix: some might be caused by Debian 
conflating "build" and "install" for Racket packages, and, in any case, they 
seem related to the "scribble" and/or "racket-index" packages, not the core 
compiler.

IIRC, there were some reproducibility issues with the Racket BC bytecode 
compiler. If we can build reproducibly with CS but not BC, it might work out to 
disable compilation for the bootstrapping BC compilers, or maybe to configure 
them to use the machine-independent format (basically, a serialized form of 
what the front-end would hand off to the back-end), at the cost of some 
performance.

I hope to work on these issues, but I plan to work on a 'racket-build-system' 
first. Among other things, I hope it will be easier to investigate issues when 
Racket packages can be built independently.

-Philip

bug#57581: Failing to build the website

[Julien Lepiller]

Le 7 septembre 2022 19:07:10 GMT+02:00, zimoun  a 
écrit :
>Hi,
>
>Well, the field reads,
>
>+(license (package-home-page qtbase
>
>so why is the compiler accepting that?  Is a warning raised?
>

No warning because the compiler has no way to know you don't want to do that. 
license is a field, and fields don't have a specific type except for convention.

package-home-page will read a field from another object, return a perfectly 
valid Scgeme object (a string) and Scheme is happy to put it in the license 
field. Why would it care? (:

It fails much later when something tries to read the license field and gets a 
string it treats as a license object.

bug#57581: Failing to build the website

[zimoun]

Hi,

On Wed, 07 Sep 2022 at 18:31, "pelzflorian (Florian Pelz)" 
 wrote:
> zimoun  writes:
>> The culprit seems the package ’qtserialport’ in ’packages-builder’ from
>> (apps packages builder).  Maybe introduced by commit
>> 1ef04fb2288dade3ad2883026ae286a68ef13a1e.
>
> This was a first failing commit for me too, but the reason the website
> does not build appears to be the license field of qtshadertools in
> commit 1d65ff8fdeb20cc2db956093f0ecb1f3f72afc0e (Cc to Maxim).  I could
> make a patch but not today.  Maxim, would you fix it?

>From my opinion, this

--8<---cut here---start->8---
+(home-page (package-home-page qtbase))
[...]
+(license (package-home-page qtbase
--8<---cut here---end--->8---

is a bad practise; instead ’(inherit qtbase)’ and rewrite all the others
fields is better.

> I don’t know if there is a way to catch such mistakes early.  Field
> sanitizers?

Well, the field reads,

+(license (package-home-page qtbase

so why is the compiler accepting that?  Is a warning raised?



Cheers,
simon

bug#57647: r-irkernel: kernel name conflict when multiple versions of R are used

[dan.munte...@mdc-berlin.de]

Hi,

I've noticed that when I install r-irkernel  it also defines the kernel
entry in {profile}/share/jupyter with ir name.

If I install again r-irkernel, but with  another R version / different
profile, the kernel name is again named ir.

This is not an issue when each profile is used independently, but, when
"joining" the two profiles under jupyterhub, (and here is the problem)
 both kernels have the same name and only one entry is displayed -
according https://github.com/IRkernel/IRkernel, multiple R versions
require different kernel names.  

Do you thin it's possible to replace the default name (ir) with
something suffixed with the R version (like ir421 for R 4.2.1)  so that
the name conflict no longer occurs with multiple R versions ?

Thank you

Best,
Dan


smime.p7s
Description: S/MIME cryptographic signature

bug#57648: python-bash-kernel : No module named bash_kernel

[dan.munte...@mdc-berlin.de]

Hi,

I've tried to use python-bash-kernel (via jupyterhub), but, even the
package installation defines  correctly the kernel

$ cat .guix-profile/share/jupyter/kernels/bash/kernel.json 
{"argv": ["/gnu/store/1m48ama708vh9cjn79yw6cj8sgg7pa1b-python-wrapper-
3.9.9/bin/python", "-m", "bash_kernel", "-f", "{connection_file}"],
"codemirror_mode": "shell", "display_name": "Bash", "env": {"PS1":
"$"}, "language": "bash"}

it fails  with the "No module found" error:

/gnu/store/1m48ama708vh9cjn79yw6cj8sgg7pa1b-python-wrapper-
3.9.9/bin/python: No module named bash_kernel

I've managed to use the kernel with one of the following workarounds:

 - define an env variable GUIX_PYTHONPATH (.bashrc or .bashprofile) set
to .guix-profile/lib/python3.9/site-packages/
 - added a new line in share/jupyter/bash/kernel.spec: "env" :
{"GUIX_PYTHONPATH":".guix-profile/lib/python3.9/site-packages/"}  - 
https://jupyter-client.readthedocs.io/en/stable/kernels.html#kernel-specs 
id="-x-evo-selection-start-marker">

Could you please adjust the package so that the kernel is able to find
the bash_kernel module ?

Thank you

Best,
Dan





smime.p7s
Description: S/MIME cryptographic signature

bug#57611: rust-once-cell (alacritty dependency) build failure

[Ben Van Sleen]

rust-once-cell-1 can't be built because it now depends on
rust-parking-lot-core-0.9. This can't be built because it now requires
rust-windows-sys-0.36 according to the crates page (
https://crates.io/crates/parking_lot_core/0.9.3/dependencies). This package
definition can be found in the guix channel that Must Not Be Named (right
next to firefox), and is not present in the main guix repo.

I would guess the reasoning behind this is that rust-windows-sys requires
some kind of nonfree code in its dependencies (perhaps
rust-windows-aarch64-msvc-0.36?). If I'm wrong about this and the package
does meet the Guix repo standards, then the alacritty problem can be fixed
by incorporating the rust-windows-sys-0.36 package definition into (gnu
packages crates-io). Would be happy to add them, but I've never submitted a
patch before (would love to start if someone wouldn't mind guiding me!) and
I'm new to the mailing list style of repo management. (I notice the
rust-windows-sys-0.28 package is included, so I assume bumping the version
up to 0.36 will be acceptable. Am testing this locally.)

Otherwise, I believe the guix-repo-only solution requires rolling back the
update to rust-once-cell in commit af39bd88a27e33c43df8324202cfebaeeb77437a.

bug#57581: Failing to build the website

[pelzflorian (Florian Pelz)]

zimoun  writes:
> The culprit seems the package ’qtserialport’ in ’packages-builder’ from
> (apps packages builder).  Maybe introduced by commit
> 1ef04fb2288dade3ad2883026ae286a68ef13a1e.

This was a first failing commit for me too, but the reason the website
does not build appears to be the license field of qtshadertools in
commit 1d65ff8fdeb20cc2db956093f0ecb1f3f72afc0e (Cc to Maxim).  I could
make a patch but not today.  Maxim, would you fix it?

I don’t know if there is a way to catch such mistakes early.  Field
sanitizers?

Regards,
Florian

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[zimoun]

Hi,

On Wed, 07 Sep 2022 at 14:51, Ludovic Courtès  wrote:

> I’d like to see what other free software OpenPGP implementors decided
> (primarily Sequoia; GnuPG/Libgcrypt implement them).

Maybe related .


Cheers,
simon

bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.

[Mathieu Othacehe]

Hey,

> * gnu/packages/linux.scm (make-linux-libre*)[arguments]:
> Remove unnecessary let clause in 'configure phase.

You should send such patches to "guix-patc...@gnu.org" instead as it is
not a bug report nor correction. Pushed as 2183db8d2 :).

Thanks,

Mathieu

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Ludovic Courtès]

Hi,

Thanks a lot for the explanations, Andreas!

As you write, the decision will be “political” as there’s no scientific
evidence to guide us.

I’d like to see what other free software OpenPGP implementors decided
(primarily Sequoia; GnuPG/Libgcrypt implement them).

Ludo’.

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Andreas Enge]

Am Wed, Sep 07, 2022 at 01:13:25PM +0200 schrieb Maxime Devos:
> Also, we _do_ have concrete evidence that the curves are flawed -- the website
> on the link mentions many issues in the process

The website (you mean the blog by D. Bernstein?) also mentions the use of
a hash function to arrive at the parameters. Maybe I overlooked something,
but I did not find other mentions of the curves (but I did not read the
page from A to Z).

> past that the NSA is in the habit of subverting communications.

But this is not concrete evidence that these curves are flawed.
As far as is publicly known, there are a few weak (and sparse) classes
of insecure elliptic curves, and the NIST curves do not belong to them.

So the only way these curves could be flawed is that there is an unknown
class of insecure curves, where the insecurity is known by the NSA.
Then if this class is sufficiently dense, one could start with a random
seed, hash the seed, and repeat until one obtains a weak instance;
see this link by a well-known cryptologist
   https://miracl.com/blog/backdoors-in-nist-elliptic-curves/
and the link given there (to another post by Bernstein).

This is possible, but speculation instead of evidence.

Newer constructions are better, but not perfect; optimally one would want
a process of "generation of public random numbers" as described here:
   https://eprint.iacr.org/2015/366

> Channels are for sharing things between multiple people.  The keys are for
> authenticating channels.  As multiple people are involved for a channel, this
> seems be be a non-personal decision by definition.

I said "political", which fits well the setting of multiple people involved.
And I meant this in opposition to "scientific", given the lack of evidence
against the NIST curves.

Andreas

bug#57642: [PATCH] gnu: linux: Fix unnecessary let clause in make-linux-libre.

[muradm]

* gnu/packages/linux.scm (make-linux-libre*)[arguments]:
Remove unnecessary let clause in 'configure phase.
---
 gnu/packages/linux.scm | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gnu/packages/linux.scm b/gnu/packages/linux.scm
index f4880f164c..ee6e592183 100644
--- a/gnu/packages/linux.scm
+++ b/gnu/packages/linux.scm
@@ -852,8 +852,7 @@ (define* (make-linux-libre* version gnu-revision source 
supported-systems
#$(and extra-version
   (string-append "-" extra-version)))
 
-   (let ((build  (assoc-ref %standard-phases 'build))
- (config (assoc-ref inputs "kconfig")))
+   (let ((config (assoc-ref inputs "kconfig")))
 
  ;; Use a custom kernel configuration file or a default
  ;; configuration file.
-- 
2.37.2

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Maxime Devos]

On 06-09-2022 22:02, Ludovic Courtès wrote:

In case of those curves, I'm not aware of any 'crytopgraphic proof'
(*) that the curves are vulnerable (unlike for SHA-1), but as noted in
¹ and elsewhere, there are other kinds of evidence that something is
wrong.

It’s different from SHA-1 though: ECDSA is not known to be vulnerable,
and AIUI we can’t tell that there’s a possibility NIST/NSA has a
backdoor as is the case for DualEC.  However, the whole NIST design
process is tainted.  So my understanding is that it’s really a gray
area.


In cryptography (and security), being a grey area and not known to be 
vulnerable is not sufficient -- rather, there has to be a reason for 
confidence that that the crypto is actually good and not-vulnerable for 
a decent amount of time.


Or, in other words, in cryptography and security there is no assumption 
of innocence -- rather, it starts with the assumption that anyone might 
be an attacker and whoever proposes a crypto thing has to convince 
others that their crypto is secure, and a communication party has to 
proof to the other party that they aren't an imposter (public key 
signing, with an previously agreed on key and algorithm).


Andreas wrote:


well, I agree with your analysis. There is no concrete evidence that the
NIST curves may be flawed, and a general belief that not all crypto
standards of NIST are flawed or backdoored... So it makes sense to accept
the curves, (and a personal decision about which type of key a user creates).
I followed you right until the conclusion, it appears that you are 
starting from an assumption of innocence, which might explain our 
different conclusions?


Also, we _do_ have concrete evidence that the curves are flawed -- the 
website on the link mentions many issues in the process and it has been 
shown in the past that the NSA is in the habit of subverting 
communications (*).


(*) I can give some sources if you don't know of them already.

Channels are for sharing things between multiple people.  The keys are 
for authenticating channels.  As multiple people are involved for a 
channel, this seems be be a non-personal decision by definition.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57576: bug#57599: [PATCH] openpgp: Add support for ECDSA with NIST curves.

[Andreas Enge]

Hello,

Am Tue, Sep 06, 2022 at 10:02:55PM +0200 schrieb Ludovic Courtès:
> (Cc’ing Andreas for extra advice.)

well, I agree with your analysis. There is no concrete evidence that the
NIST curves may be flawed, and a general belief that not all crypto
standards of NIST are flawed or backdoored... So it makes sense to accept
the curves, but ultimately this is a political decision (and a personal
decision about which type of key a user creates).

Andreas