bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default
On 3/9/21 6:03 PM, L A Walsh wrote: Thanks for the update and appreciate your diligence... You're welcome. Closing the bug report.
bug#47014: Design flaw: incompatible touch '-f' gnu-option causes loss of (meta)data by default
On 2021/03/08 19:58, Paul Eggert wrote: On 3/8/21 6:29 PM, L A Walsh wrote: Warning, '-f' assuming '-r' was intended I don't think that'd be helpful, given that -f now has a well-defined and common meaning that doesn't agree with what you remember, and that in 4.2BSD (circa 1983) -f meant something quite different from -r and the common current interpretation of -f (which is to ignore it) is extremely compatible with 4.2BSD's interpretation. See: https://www.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/man/man1/touch.1 Indeed! I wondered about a '-f' ala force...well given that, sigh. I'm probably thinking of a -f meaning some file to use from some other util... Thanks for the update and appreciate your diligence...
bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000
On 3/9/21 4:58 AM, Philippe Bénézech via GNU coreutils Bug Reports wrote: df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) $ df -BGB /home Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2 421GB 355GB 45GB 89% /home $ df -H /home Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/mapper/ssd2 421G 355G 45G 89% /home I don't see a bug here. First, I assume you meant to write "GB" rather than "GM". Second, "df -BGB" is documented to append units (in this case, "GB") to the output number, whereas "df -H" is merely documented to append a size indication (in this case, "G").
bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000
unarchive 18119 forcemerge 18119 47023 stop On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote: Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df --version |head -1 df (GNU coreutils) 8.30 $ cat /etc/debian_version 10.8 df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) This is not restricted to G $ df -BGB /home Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2421GB 355GB 45GB 89% /home $ df -H /home Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/mapper/ssd2 421G355G 45G 89% /home In summary df -H is outputting with a concise single letter, which is indistinguishable from that of df -h. I agree that's not ideal as the output can't be interpreted without the command as context. I.e. it restricts usage to direct command line usage. A possible change we could make here would be to use GB, MB etc. if --si is specified. But also -h and -H are not really useful outside of direct cli usage, I'm 50:50 on changing this. This was originally discussed at https://bugs.gnu.org/18119 Mentioned there is an option to use the new numfmt functionality to provide more control and unambiguous output. BTW the fact that a B suffix implies SI units is awkward in the first place, which I've documented the reasons for at: https://www.pixelbeat.org/docs/coreutils-gotchas.html#units cheers, Pádraig
bug#45358: bootstrap fails due to a certificate mismatch
Erik Auerswald wrote: > Grigoriy Sokolik wrote: > > I've rechecked: > > I cannot reproduce the problem, the certificate is trusted by my system: > > # via IPv4 > $ gnutls-cli --verbose translationproject.org 'Connecting|Status' > Connecting to '80.69.83.146:443'... > - Status: The certificate is trusted. > # via IPv6 > $ gnutls-cli --verbose translationproject.org 'Connecting|Status' > Connecting to '2a01:7c8:c037:6::20:443'... > - Status: The certificate is trusted. I have the same results here. Everything looks okay in the inspection of it. > It seems to me as if your system does not trust the used root CA. > > > [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.'[...] > > On my Ubuntu 18.04 system, I find it via symlink from /etc/ssl/certs: > > $ ls /etc/ssl/certs/DST_Root_CA_X3.pem -l > lrwxrwxrwx 1 root root 53 Mai 28 2018 /etc/ssl/certs/DST_Root_CA_X3.pem > -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt > $ certtool --certificate-info < > /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt | grep Subject: > Subject: CN=DST Root CA X3,O=Digital Signature Trust Co. Again same here on my Debian system. The root certificate store for the trust anchor is in the ca-certificates package. Looking at my oldest system I see this is distributed as package version 20200601~deb9u1 and includes the above file. $ apt-cache policy ca-certificates ca-certificates: Installed: 20200601~deb9u1 Candidate: 20200601~deb9u1 Version table: *** 20200601~deb9u1 500 500 http://ftp.us.debian.org/debian stretch/main amd64 Packages 500 http://ftp.us.debian.org/debian stretch-updates/main amd64 Packages 100 /var/lib/dpkg/status Verifying that the equivalent of ca-certificates is installed on your system should provide for it. As this seems not to be a bug in Coreutils I am marking the bug as closed with this mail. However more discussion is always welcome. Bob
bug#47023: df utilility displays G instead of GM as unit size for Gigabytes in power of 1000
Dear maintener, I found a reproducible bug in df utility, installed in debian stable $ df --version |head -1 df (GNU coreutils) 8.30 $ cat /etc/debian_version 10.8 df displays G instead of GM as unit size for Gigabytes in power of 1000 (but the value is correct) $ df -BGB /home Sys. de fichiers blocs de 1GB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2421GB 355GB 45GB 89% /home $ df -H /home Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur /dev/mapper/ssd2 421G355G 45G 89% /home As a remark, the display is ok (no bug) with TeraBytes, MegaBytes and KiloBytes in power of 1000 $ df -BTB /home Sys. de fichiers blocs de 1TB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2 1TB 1TB1TB 89% /home $ df -BMB /home Sys. de fichiers blocs de 1MB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2 420611MB 354492MB44682MB 89% /home $ df -BKB /home Sys. de fichiers blocs de 1kB Utilisé Disponible Uti% Monté sur /dev/mapper/ssd2 420610057kB 354491245kB 44681065kB 89% /home Best regards
bug#45358: bootstrap fails due to a certificate mismatch
Hi, On Tue, Mar 09, 2021 at 11:28:18AM +0200, Grigoriy Sokolik wrote: > I've rechecked: I cannot reproduce the problem, the certificate is trusted by my system: # via IPv4 $ gnutls-cli --verbose translationproject.org [...]issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.'[...] On my Ubuntu 18.04 system, I find it via symlink from /etc/ssl/certs: $ ls /etc/ssl/certs/DST_Root_CA_X3.pem -l lrwxrwxrwx 1 root root 53 Mai 28 2018 /etc/ssl/certs/DST_Root_CA_X3.pem -> /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt $ certtool --certificate-info < /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt | grep Subject: Subject: CN=DST Root CA X3,O=Digital Signature Trust Co. HTH, Erik -- [A]pplied cryptography mostly sucks. -- Green's law of applied cryptography
bug#45358: bootstrap fails due to a certificate mismatch
I've rechecked: ``` $ gnutls-cli translationproject.org Processed 139 CA certificate(s). Resolving 'translationproject.org:443'... Connecting to '80.69.83.146:443'... - Certificate type: X.509 - Got a certificate list of 3 certificates. - Certificate[0] info: - subject `CN=stats.vrijschrift.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x043ecc3aacb8c85e4b142ad6a502a8e749c7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-03-01 10:34:36 UTC', expires `2021-05-30 10:34:36 UTC', pin-sha256="rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA=" Public Key ID: sha1:351b768332605268f158f75cc602b700c8950d71 sha256:aec69b280aa2ea099bc1f926d8a8faf64324f6f71e335a4eac8b12589dbd6b10 Public Key PIN: pin-sha256:rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA= - Certificate[1] info: - subject `CN=stats.vrijschrift.org', issuer `CN=R3,O=Let's Encrypt,C=US', serial 0x043ecc3aacb8c85e4b142ad6a502a8e749c7, RSA key 4096 bits, signed using RSA-SHA256, activated `2021-03-01 10:34:36 UTC', expires `2021-05-30 10:34:36 UTC', pin-sha256="rsabKAqi6gmbwfkm2Kj69kMk9vceM1pOrIsSWJ29axA=" - Certificate[2] info: - subject `CN=R3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x400175048314a4c8218c84a90c16cddf, RSA key 2048 bits, signed using RSA-SHA256, activated `2020-10-07 19:21:40 UTC', expires `2021-09-29 19:21:40 UTC', pin-sha256="jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=" - Status: The certificate is NOT trusted. The certificate issuer is unknown. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. ``` ``` $ openssl s_client -connect translationproject.org:443 -CApath /etc/ssl/certs -showcerts /dev/null | sed -n '/^-BEGIN CERTIFICATE-/,/^-END CERTIFICATE-/p' > /tmp/translationproject.org.certs $ certtool --verbose --verify-profile=high --verify --infile=/tmp/translationproject.org.certs Loaded system trust (139 CAs available) Subject: CN=stats.vrijschrift.org Issuer: CN=R3,O=Let's Encrypt,C=US Signature algorithm: RSA-SHA256 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Subject: CN=stats.vrijschrift.org Issuer: CN=R3,O=Let's Encrypt,C=US Signature algorithm: RSA-SHA256 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Subject: CN=stats.vrijschrift.org Issuer: CN=R3,O=Let's Encrypt,C=US Signature algorithm: RSA-SHA256 Output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. Chain verification output: Not verified. The certificate is NOT trusted. The certificate issuer is unknown. ``` Thanks! Best regards, Grigorii On Tue, 9 Mar 2021 at 07:55, Bob Proulx wrote: > Is this problem still a problem? Perhaps it has been fixed in the > time this has been under discussion? Because it looks okay to me. > > Grigoriy Sokolik wrote: > >$ curl -v https://translationproject.org/latest/coreutils/ -o > /dev/null > ... > >* Connected to translationproject.org (80.69.83.146) port 443 (#0) > ... > >* successfully set certificate verify locations: > >* CAfile: /etc/ssl/certs/ca-certificates.crt > >* CApath: none > > I suspect this last line to be the root cause of the problem. There > is no CApath and therefore no root anchoring certificates trusted. > Without that I don't see how any certificates can be trusted. > > I do the same test here and see this. > > $ curl -v https://translationproject.org/latest/coreutils/ -o > /dev/null > ... > * Connected to translationproject.org (80.69.83.146) port 443 (#0) > ... > * successfully set certificate verify locations: > * CAfile: /etc/ssl/certs/ca-certificates.crt > * CApath: /etc/ssl/certs > > Note the inclusion of the trusted root path. > > * Server certificate: > * subject: CN=stats.vrijschrift.org > * start date: Mar 1 10:34:36 2021 GMT > * expire date: May 30 10:34:36 2021 GMT > * subjectAltName: host "translationproject.org" matched cert's > * "translationproject.org" > * issuer: C=US; O=Let's Encrypt; CN=R3 > * SSL certificate verify ok. > > Note that the certificate validates as okay. > > Also if I simply ask openssl to validate: > > $ openssl s_client -connect translationproject.org:443 -CApath > /etc/ssl/certs -showcerts /dev/null > ... > Verify return code: 0 (ok) > > If I download all of the certificates and validate using certtool, > since you mentioned certtool I will use your example: > > $ openssl s_client -connect translationproject.org:443 -CApath > /etc/ssl/certs -showcerts /dev/null | sed -n '/^-BEGIN > CERTIFICATE-/,/^-END CERTIFICATE-/p' > /tmp/ > translationproject.org.certs > $ certtool --verbose --verify-profile=high --verify > --infile=/tmp/translationproject.org.certs >
