[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
For me the fact that the upstream repo moved from bugzilla.samba.org to github.com is sufficient to diverge from upstream. But to each his own. My contempt for github is in fact why I reported the bug downstream. I will not use github but I still intended to make a public record of the bug, hence why it's here. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1925381 Title: rsync conceals file deletions from reporting when --dry-run --remove- source-files are used together Status in rsync package in Ubuntu: Triaged Bug description: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) inhibits reporting of file deletions when --remove-source-files is used. This is quite serious. People use --dry-run to see if an outcome will work as expected before a live run. When the simulated run shows *less* destruction than the live run, the consequences can be serious because rsync may unexpectedly destroy the only copy(*) of a file. Users rely on --dry-run. Although users probably expect --dry-run to have limitations, we don't expect destructive operations to be under reported. If it were reversed, such that the live run were less destructive than the dry run, this wouldn't be as serious. Reproducer: $ mkdir -p /tmp/src /tmp/dest $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt $ cp /tmp/src/foo.txt /tmp/dest $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt foo.txt $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/ (no output) $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/ sender removed foo.txt $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt (*) note when I say it can destroy the only copy of a file, another circumstance is needed: that is, rsync does not do a checksum by default. It checks for identical files based on superficial parameters like name and date. So it's possible that two files match in the default superficial comparison but differ in the actual content. Losing a unique file in this scenario is perhaps a rare corner case, but this bug should be fixed nonetheless. In the typical case of losing files at the source, there is still a significant inconvenience of trying to identify what files to copy back. Note this bug is similar but differs in a few ways: https://bugzilla.samba.org/show_bug.cgi?id=3844 I've marked this as a security vulnerability because it causes unexpected data loss due to --dry-run creating a false expectation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1925381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929087] [NEW] sfdisk refuses to write GPT table between sector 34 and 2047
Public bug reported: According to https://wiki.archlinux.org/title/GRUB#BIOS_systems, it's both legal and interesting to place the BIOS BOOT partition from sector 34 to sector 2047, as follows: $ sudo sfdisk --no-act -f --label gpt /dev/sdb << EOF start= 34, size=2013, name=bios, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /bios boot/{print $1}') start= 2048, size=12582912, name=swap, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux swap/{print $1}') EOF The output is: /dev/sdb1: Sector 34 already used. Failed to add #1 partition: Numerical result out of range Leaving. It's a false error. As a workaround, users must omit the BIOS BOOT partition then use gdisk to insert it manually. This was uncovered in 2015 and perhaps never reported to a bug tracker because it's still broken. See https://www.spinics.net/lists/util-linux-ng/msg11253.html ** Affects: util-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1929087 Title: sfdisk refuses to write GPT table between sector 34 and 2047 Status in util-linux package in Ubuntu: New Bug description: According to https://wiki.archlinux.org/title/GRUB#BIOS_systems, it's both legal and interesting to place the BIOS BOOT partition from sector 34 to sector 2047, as follows: $ sudo sfdisk --no-act -f --label gpt /dev/sdb << EOF start= 34, size=2013, name=bios, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /bios boot/{print $1}') start= 2048, size=12582912, name=swap, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux swap/{print $1}') EOF The output is: /dev/sdb1: Sector 34 already used. Failed to add #1 partition: Numerical result out of range Leaving. It's a false error. As a workaround, users must omit the BIOS BOOT partition then use gdisk to insert it manually. This was uncovered in 2015 and perhaps never reported to a bug tracker because it's still broken. See https://www.spinics.net/lists/util-linux-ng/msg11253.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1929087/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1929087] Re: sfdisk refuses to write GPT table between sector 34 and 2047
A secondary bug manifests from this, whereby sfdisk chokes on its own output and therefore cannot restore its own backup. E.g. suppose another tool is used to put a BIOS boot partition from sector 34 to 2047, as follows: $ sgdisk --clear -a 1 --new=1:34:2047 -c 1:"BIOS boot" --typecode=1:$(sgdisk --list-types | sed -ne 's/.*\(\).bios.*/\1/gip') /dev/sdb That works fine, and from that we can run "sfdisk -d /dev/sdb > dump.txt". But when dump.txt is fed back into sfdisk, it pukes. Yet the docs claim "It is recommended to save the layout of your devices. sfdisk supports two ways." .. "Use the --dump option to save a description of the device layout to a text file." .. "This can later be restored by: sfdisk /dev/sda < sda.dump" It's actually a security issue, because someone can make an non- restorable backup and have the false sense of security that it is restorable. They wouldn't necessary test restoration either because that's a destructive process. ** Description changed: According to https://wiki.archlinux.org/title/GRUB#BIOS_systems, it's both legal and interesting to place the BIOS BOOT partition from sector 34 to sector 2047, as follows: $ sudo sfdisk --no-act -f --label gpt /dev/sdb << EOF start= 34, size=2013, name=bios, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /bios boot/{print $1}') start= 2048, size=12582912, name=swap, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux swap/{print $1}') EOF The output is: /dev/sdb1: Sector 34 already used. Failed to add #1 partition: Numerical result out of range Leaving. - It's a false error. As a workaround, users must omit the BIOS BOOT - partition then use gdisk to insert it manually. This was uncovered in - 2015 and perhaps never reported to a bug tracker because it's still - broken. See https://www.spinics.net/lists/util-linux-ng/msg11253.html + It's a false error. As a workaround, users must use parted or sgdisk + instead. (note fdisk & gdisk are also broken in the same way) + + This bug was uncovered in 2015 and perhaps never reported to a bug + tracker because it's still broken. See https://www.spinics.net/lists + /util-linux-ng/msg11253.html -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1929087 Title: sfdisk refuses to write GPT table between sector 34 and 2047 Status in util-linux package in Ubuntu: New Bug description: According to https://wiki.archlinux.org/title/GRUB#BIOS_systems, it's both legal and interesting to place the BIOS BOOT partition from sector 34 to sector 2047, as follows: $ sudo sfdisk --no-act -f --label gpt /dev/sdb << EOF start= 34, size=2013, name=bios, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /bios boot/{print $1}') start= 2048, size=12582912, name=swap, type=$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux swap/{print $1}') EOF The output is: /dev/sdb1: Sector 34 already used. Failed to add #1 partition: Numerical result out of range Leaving. It's a false error. As a workaround, users must use parted or sgdisk instead. (note fdisk & gdisk are also broken in the same way) This bug was uncovered in 2015 and perhaps never reported to a bug tracker because it's still broken. See https://www.spinics.net/lists /util-linux-ng/msg11253.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1929087/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1930139] [NEW] the --no-directories option incorrectly documented in the man page
Public bug reported: man page shows: -nd --no-directories Do not create a hierarchy of directories when retrieving recursively. With this option turned on, all files will get saved to the current directory, without clobbering (if a name shows up more than once, the filenames will get extensions .n). The way that's written implies that the -nd option would conflict with the -P option. But when -nd is combined with --directory-prefix (-P), wget honors the prefix and also downloads to a flat non-hierarchical "structure". The behavior is sensible but the docs are wrong (-nd does not necessarily download to the current dir). ** Affects: wget (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1930139 Title: the --no-directories option incorrectly documented in the man page Status in wget package in Ubuntu: New Bug description: man page shows: -nd --no-directories Do not create a hierarchy of directories when retrieving recursively. With this option turned on, all files will get saved to the current directory, without clobbering (if a name shows up more than once, the filenames will get extensions .n). The way that's written implies that the -nd option would conflict with the -P option. But when -nd is combined with --directory-prefix (-P), wget honors the prefix and also downloads to a flat non-hierarchical "structure". The behavior is sensible but the docs are wrong (-nd does not necessarily download to the current dir). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1930139/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 978587] Re: apt should ensure .deb are not corrupted before handing them to dpkg
This is actually a security issue and it's surprising it's gone unfixed for 9 years. It's inconsistent for apt to check the hash on deb files that it downloads, but then neglect to do so on user-supplied deb files. The status quo is a recipe for disaster. To exacerbate the problem, the man page does not document the inconsistency or the fact that . There are a variety of ways to fix this: 1) apt could refuse to accept local .deb files 2) apt could require local .deb files to be supplied with a hash string (which would need a new CLI arg) 3) apt could print the hash to the string and instruct the user to confirm whether the hash matches 4) apt could check the repos it's aware of to see if the hash matches anything served by a trusted repo. If not, follow option 1 or 3 above. It's also important to note that users don't generally know how deb files are structured or how deb files are structured. Should they be responsible for knowing whether a hash is embedded within the deb file or not? Particularly when the man page makes no mention of it? Generally, the user might know that hashes are checked by the apt-* tools one way or another. The apt suite of tools (and docs for it) keep the user in the dark, and yet the user is responsible knowing how it works. The user is not served well in this case. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/978587 Title: apt should ensure .deb are not corrupted before handing them to dpkg Status in apt package in Ubuntu: Confirmed Bug description: Upon upgrading to libreoffice-core 3.5.2 version, I stumbled upon what seems to be a bad download issue: Preparing to replace libreoffice-core 1:3.5.1-1ubuntu5 (using .../libreoffice-core_1%3a3.5.2-2ubuntu1_amd64.deb) ... rmdir: failed to remove `/var/lib/libreoffice/basis3.4/program/': No such file or directory rmdir: failed to remove `/var/lib/libreoffice/basis3.4': No such file or directory Unpacking replacement libreoffice-core ... dpkg-deb (subprocess): data: internal bzip2 read error: 'DATA_ERROR' dpkg-deb: error: subprocess returned error exit status 2 dpkg: error processing /var/cache/apt/archives/libreoffice-core_1%3a3.5.2-2ubuntu1_amd64.deb (--unpack): subprocess dpkg-deb --fsys-tarfile returned error exit status 2 I was asked to file a bug about it, as it might be possible for dpkg to recover from that more gracefully. Further information upon requests. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/978587/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1931815] [NEW] the %{remote_ip} output format is broken on proxied connections
Public bug reported: This is how a Tor user would use cURL to grab a header, and also expect to be told which IP address was contacted: curl --ssl --socks4a 127.0.0.1:9050 -L --head -w '(effective URL => "%{url_effective} @ %{remote_ip}")' "$target_url" It's broken because the "remote_ip" is actually just printed as the 127.0.0.1 (likely that of the proxy server not the remote target host). tested on curl ver 7.52.1 ** Affects: curl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1931815 Title: the %{remote_ip} output format is broken on proxied connections Status in curl package in Ubuntu: New Bug description: This is how a Tor user would use cURL to grab a header, and also expect to be told which IP address was contacted: curl --ssl --socks4a 127.0.0.1:9050 -L --head -w '(effective URL => "%{url_effective} @ %{remote_ip}")' "$target_url" It's broken because the "remote_ip" is actually just printed as the 127.0.0.1 (likely that of the proxy server not the remote target host). tested on curl ver 7.52.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1931815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1931815] Re: the %{remote_ip} output format is broken on proxied connections
According to the SOCKS4a spec: https://www.openssh.com/txt/socks4.protocol https://www.openssh.com/txt/socks4a.protocol With SOCKS4 cURL *must* do DNS resolution and pass the selected IP to the SOCKS server. OTOH, SOCKS4a gives cURL the option to resolve. If cURL fails at DNS resolution, it's expected to send the hostname and 0.0.0.x. So generally cURL should succeed at DNS resolution and thus have the IP of the target server. Yet it's not sharing that info with the user. SOCKS4a was a bad test case because we can't know whether or not cURL did the DNS resolution. A better test case is with SOCKS4 as follows: curl --ssl --socks4 127.0.0.1:9050 -L --head -w '(effective URL => "%{url_effective} @ %{remote_ip}")' "$target_url" We are assured per the SOCKS4 protocol that cURL *must* do DNS resolution, so cURL must know the remote IP address. Yet it still neglects to correctly set the %{remote_ip} value. This is certainly a bug. Secondary bug-- the manpage states: "remote_ip The remote IP address of the most recently done connection - can be either IPv4 or IPv6 (Added in 7.29.0)" The man page is ambiguous. The /rule of least astonishment/ would have the user naturally expecting "remote IP" to be the target IP whenever cURL knows it. Since the behavior is non-intuitive, the man page should state in detail what the user should expect to receive for the %{remote_ip} value. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1931815 Title: the %{remote_ip} output format is broken on proxied connections Status in curl package in Ubuntu: New Bug description: This is how a Tor user would use cURL to grab a header, and also expect to be told which IP address was contacted: curl --ssl --socks4a 127.0.0.1:9050 -L --head -w '(effective URL => "%{url_effective} @ %{remote_ip}")' "$target_url" It's broken because the "remote_ip" is actually just printed as the 127.0.0.1 (likely that of the proxy server not the remote target host). tested on curl ver 7.52.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1931815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1931815] Re: the %{remote_ip} output format is broken on proxied connections
The socks.c code shows that cURL does not even attempt DNS resolution on SOCKS4a. Strictly speaking, the SOCKS4a spec expects apps to /attempt/ DNS resolution before contacting the socks server. I won't complain on this point though because the status quo is favorable to Tor users (as it protects them from DNS leaks). The fallout is that the SOCKS server does not give feedback to the app on the IP it settles on in the socks4a scenario. This means cURL has no possible way of knowing which IP to express in the %{remote_ip} output. After seeing the code I'm calling out these bugs: bug 1) SOCKS4a: Considering that Curl_resolve() is unconditionally bypassed, when a user supplies both --resolve and also demands socks4a cURL will neglect to honor the --resolve option even though the two options are theoretically compatible. This is a minor bug because socks4 can be used instead as a workaround. But certainly the man page should at a minimum disclose the artificial incompatibility between socks4a and --resolve. bug 2) SOCKS4a docs: cURL has some discretion whether to attempt DNS resolution or not. Yet the docs do not clarify. Users should get reassurance in the man page that using socks4a unconditionally refrains from internal DNS resolution. bug 3) SOCKS4: Since cURL *must* do DNS resolution, cURL must also know what the target IP is. Thus cURL should properly return the %{remote_ip} value. bug 4) The docs for %{remote_ip} should tell users what to expect for that value. The man page is vague enough to be useless. Workaround: if proxy users need to know which IP cURL connected to, they must do their own DNS resolution manually outside of cURL (e.g. using dig), supply the IP & hostname via --resolve, and use SOCKS4 or SOCKS5 (not SOCKS4a). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1931815 Title: the %{remote_ip} output format is broken on proxied connections Status in curl package in Ubuntu: New Bug description: This is how a Tor user would use cURL to grab a header, and also expect to be told which IP address was contacted: curl --ssl --socks4a 127.0.0.1:9050 -L --head -w '(effective URL => "%{url_effective} @ %{remote_ip}")' "$target_url" It's broken because the "remote_ip" is actually just printed as the 127.0.0.1 (likely that of the proxy server not the remote target host). tested on curl ver 7.52.1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1931815/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1933913] [NEW] "Xorg -configure" results in "modprobe: FATAL: Module fbcon not found in directory /lib/modules/5.10.0-7-amd64"
Public bug reported: With x11 not running, this was executed: "Xorg -configure". It should simply build a configuration file. The output below appears in the terminal with an error. It manages to create a config file anyway, but what it creates causes "startx" to fall over. So I am forced to run x11 without a config file (which is a problem for me because I have two displays and need to change the RightOf/LeftOf setting). OUTPUT: X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 Build Operating System: linux Debian Current Operating System: Linux billyikes 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-7-amd64 root=/dev/mapper/grp-root ro rd.luks.name=UUID=279a24dc-1014-6495-38cc-75ce88144f44=cryptdisk quiet Build Date: 13 April 2021 04:07:31PM xorg-server 2:1.20.11-1 (https://www.debian.org/support) Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 29 02:19:12 2021 List of video drivers: amdgpu ati intel nouveau qxl radeon vmware modesetting fbdev vesa (++) Using config file: "/root/xorg.conf.new" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" modprobe: FATAL: Module fbcon not found in directory /lib/modules/5.10.0-7-amd64 intel: waited 2020 ms for i915.ko driver to load Number of created screens does not match number of detected devices. Configuration failed. (EE) Server terminated with error (2). Closing log file. ** Affects: xorg (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to xorg in Ubuntu. https://bugs.launchpad.net/bugs/1933913 Title: "Xorg -configure" results in "modprobe: FATAL: Module fbcon not found in directory /lib/modules/5.10.0-7-amd64" Status in xorg package in Ubuntu: New Bug description: With x11 not running, this was executed: "Xorg -configure". It should simply build a configuration file. The output below appears in the terminal with an error. It manages to create a config file anyway, but what it creates causes "startx" to fall over. So I am forced to run x11 without a config file (which is a problem for me because I have two displays and need to change the RightOf/LeftOf setting). OUTPUT: X.Org X Server 1.20.11 X Protocol Version 11, Revision 0 Build Operating System: linux Debian Current Operating System: Linux billyikes 5.10.0-7-amd64 #1 SMP Debian 5.10.40-1 (2021-05-28) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-7-amd64 root=/dev/mapper/grp-root ro rd.luks.name=UUID=279a24dc-1014-6495-38cc-75ce88144f44=cryptdisk quiet Build Date: 13 April 2021 04:07:31PM xorg-server 2:1.20.11-1 (https://www.debian.org/support) Current version of pixman: 0.40.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 29 02:19:12 2021 List of video drivers: amdgpu ati intel nouveau qxl radeon vmware modesetting fbdev vesa (++) Using config file: "/root/xorg.conf.new" (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" modprobe: FATAL: Module fbcon not found in directory /lib/modules/5.10.0-7-amd64 intel: waited 2020 ms for i915.ko driver to load Number of created screens does not match number of detected devices. Configuration failed. (EE) Server terminated with error (2). Closing log file. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1933913/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934040] [NEW] openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely!
Public bug reported: SSL2 and SSL3 have been hastily removed, apparently by developers who are unaware that these protocols serve purposes other than encryption. SSL2/3 is *still used* on onion sites. Why? For verification. An onion site has inherent encryption, so it matters not how weak the SSL crypto is when the purpose is purely to verify that the server is owned by who they say it's owned by. Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites: https://blog.torproject.org/tls-certificate-for-onion-site So here is a real world impact case. Suppose you get your email from one of these onion mail servers: http://onionmail.info/directory.html Some (if not all) use ssl2/3 on top of Tor's inherent onion tunnel. They force users to use ssl2/3, so even if a user configures the client not to impose TLS, the server imposes it. And it's reasonable because the ssl2/3 vulns are orthoganol to the use case. Some users will get lucky and use a mail client that still supports ssl2/3. But there's still a problem: users can no longer use openssl to obtain the fingerprint to pin. e.g. $ openssl s_client -proxy 127.0.0.1:8118 -connect xhfheq5i37waj6qb.onion:110 -showcerts CONNECTED(0003) 140124399195456:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 44 bytes and written 330 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- That's openssl version 1.1.1k Being denied the ability to pin the SSL cert is actually a *degredation* of security. Cert Pinning is particularly useful with self-signed certs, as is often the scenario with onion sites. ** Affects: openssl (Ubuntu) Importance: Undecided Status: New ** Description changed: SSL2 and SSL3 have been hastily removed, apparently by developers who are unaware that these protocols serve purposes other than encryption. SSL2/3 is *still used* on onion sites. Why? For verification. An onion site has inherent encryption, so it matters not how weak the SSL crypto is when the purpose is purely to verify that the server is owned by who they say it's owned by. Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites: https://blog.torproject.org/tls-certificate-for-onion-site So here is a real world impact case. Suppose you get your email from one of these onion mail servers: http://onionmail.info/directory.html Some (if not all) use ssl2/3 on top of Tor's inherent onion tunnel. They force users to use ssl2/3, so even if a user configures the client not to impose TLS, the server imposes it. And it's reasonable because the ssl2/3 vulns are orthoganol to the use case. Some users will get lucky and use a mail client that still supports ssl2/3. But there's still a problem: users can no longer use openssl to obtain the fingerprint to pin. e.g. $ openssl s_client -proxy 127.0.0.1:8118 -connect xhfheq5i37waj6qb.onion:110 -showcerts CONNECTED(0003) 140124399195456:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 44 bytes and written 330 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- + That's openssl version 1.1.1k - That's openssl version 1.1.1k + Being denied the ability to pin the SSL cert is actually a *degredation* + of security. Cert Pinning is particularly useful with self-signed + certs, as is often the scenario with onion sites. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1934040 Title: openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely! Status in openssl package in Ubuntu: New Bug description: SSL2 and SSL3 have been hastily removed, apparently by developers who are unaware that these protocols serve purposes other than encryption. SSL2/3 is *still used* on onion sites. Why? For verification. An onion site has inherent encryption, so it matters not how weak the SSL crypto is when the purpose is purely to verify that the server is owned by who they say it's owned by. Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites: https://blog.torproject.org/tls-certificate-for-onion-site So here is a real world impact case. Suppose you get your email from one of these onion mail servers: http://onionmail.info/directory.html
[Touch-packages] [Bug 1934044] [NEW] openssl removed ssl2/3 and broke cURL because curl uses openssl instead of libssl
Public bug reported: cURL supports a -ssl3 option (and rightly so), but openssl removed it prematurely (see https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1934040). The fallout: torsocks curl --insecure --ssl-allow-beast -ssl3 -vvI https://xhfheq5i37waj6qb.onion:110 2>&1 * Trying 127.42.42.0:110... * Connected to xhfheq5i37waj6qb.onion (127.42.42.0) port 110 (#0) * OpenSSL was built without SSLv3 support * Closing connection 0 Is it possible that curl's check for ssl3 is flawed? I say that because both curl and fetchmail are dependant on the same libssl pkg, and yet fetchmail can still do ssl3 but curl can't. Neither curl nor fetchmail names "openssl" as a dependency. So curl perhaps should not look to the openssl package to detect ssl3 capability. SSL3 is still useful for onion sites, so curl should do the necessary to retain that capability. ** Affects: curl (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/1934044 Title: openssl removed ssl2/3 and broke cURL because curl uses openssl instead of libssl Status in curl package in Ubuntu: New Bug description: cURL supports a -ssl3 option (and rightly so), but openssl removed it prematurely (see https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1934040). The fallout: torsocks curl --insecure --ssl-allow-beast -ssl3 -vvI https://xhfheq5i37waj6qb.onion:110 2>&1 * Trying 127.42.42.0:110... * Connected to xhfheq5i37waj6qb.onion (127.42.42.0) port 110 (#0) * OpenSSL was built without SSLv3 support * Closing connection 0 Is it possible that curl's check for ssl3 is flawed? I say that because both curl and fetchmail are dependant on the same libssl pkg, and yet fetchmail can still do ssl3 but curl can't. Neither curl nor fetchmail names "openssl" as a dependency. So curl perhaps should not look to the openssl package to detect ssl3 capability. SSL3 is still useful for onion sites, so curl should do the necessary to retain that capability. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1934044/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1934040] Re: openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely!
** Description changed: SSL2 and SSL3 have been hastily removed, apparently by developers who are unaware that these protocols serve purposes other than encryption. SSL2/3 is *still used* on onion sites. Why? For verification. An onion site has inherent encryption, so it matters not how weak the SSL crypto is when the purpose is purely to verify that the server is owned by who they say it's owned by. Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites: https://blog.torproject.org/tls-certificate-for-onion-site + https://community.torproject.org/onion-services/overview/ So here is a real world impact case. Suppose you get your email from one of these onion mail servers: http://onionmail.info/directory.html Some (if not all) use ssl2/3 on top of Tor's inherent onion tunnel. They force users to use ssl2/3, so even if a user configures the client not to impose TLS, the server imposes it. And it's reasonable because the ssl2/3 vulns are orthoganol to the use case. Some users will get lucky and use a mail client that still supports ssl2/3. But there's still a problem: users can no longer use openssl to obtain the fingerprint to pin. e.g. $ openssl s_client -proxy 127.0.0.1:8118 -connect xhfheq5i37waj6qb.onion:110 -showcerts CONNECTED(0003) 140124399195456:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 44 bytes and written 330 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- That's openssl version 1.1.1k Being denied the ability to pin the SSL cert is actually a *degredation* of security. Cert Pinning is particularly useful with self-signed certs, as is often the scenario with onion sites. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1934040 Title: openssl s_client's '-ssl2' & '-ssl3' options gone, prematurely! Status in openssl package in Ubuntu: New Bug description: SSL2 and SSL3 have been hastily removed, apparently by developers who are unaware that these protocols serve purposes other than encryption. SSL2/3 is *still used* on onion sites. Why? For verification. An onion site has inherent encryption, so it matters not how weak the SSL crypto is when the purpose is purely to verify that the server is owned by who they say it's owned by. Proof that disclosure attacks on ssl2/3 are irrelevant to onion sites: https://blog.torproject.org/tls-certificate-for-onion-site https://community.torproject.org/onion-services/overview/ So here is a real world impact case. Suppose you get your email from one of these onion mail servers: http://onionmail.info/directory.html Some (if not all) use ssl2/3 on top of Tor's inherent onion tunnel. They force users to use ssl2/3, so even if a user configures the client not to impose TLS, the server imposes it. And it's reasonable because the ssl2/3 vulns are orthoganol to the use case. Some users will get lucky and use a mail client that still supports ssl2/3. But there's still a problem: users can no longer use openssl to obtain the fingerprint to pin. e.g. $ openssl s_client -proxy 127.0.0.1:8118 -connect xhfheq5i37waj6qb.onion:110 -showcerts CONNECTED(0003) 140124399195456:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../ssl/record/ssl3_record.c:331: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 44 bytes and written 330 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- That's openssl version 1.1.1k Being denied the ability to pin the SSL cert is actually a *degredation* of security. Cert Pinning is particularly useful with self-signed certs, as is often the scenario with onion sites. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1934040/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1916341] [NEW] poppler-utils/pdfimages list function names the wrong color in output table
Public bug reported: When running: $ pdfimages -list grayscale-document.pdf the output is: ``` page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio 1 0 image2556 3288 rgb 3 8 jpeg no 7 0 301 300 200K 0.8% 2 1 image2556 3288 rgb 3 8 jpeg no12 0 301 300 275K 1.5% 3 2 image2556 3288 rgb 3 8 jpeg no17 0 301 300 395K 0.8% 4 3 image2556 3288 rgb 3 8 jpeg no22 0 301 300 583K 2.8% 5 4 image2556 3288 rgb 3 8 jpeg no27 0 301 300 317K 1.3% ... ``` "rgb" is incorrect, which is evident after running: 'pdfimages -all -f 1 -l 1 grayscale-document.pdf foo && identify -format "%[type]" foo-000.jpg', which correctly outputs "Grayscale". Strangely, when "pdfimages -list" is fed a bilevel document, it states that every page has color "gray". ** Affects: poppler (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to poppler in Ubuntu. https://bugs.launchpad.net/bugs/1916341 Title: poppler-utils/pdfimages list function names the wrong color in output table Status in poppler package in Ubuntu: New Bug description: When running: $ pdfimages -list grayscale-document.pdf the output is: ``` page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio 1 0 image2556 3288 rgb 3 8 jpeg no 7 0 301 300 200K 0.8% 2 1 image2556 3288 rgb 3 8 jpeg no12 0 301 300 275K 1.5% 3 2 image2556 3288 rgb 3 8 jpeg no17 0 301 300 395K 0.8% 4 3 image2556 3288 rgb 3 8 jpeg no22 0 301 300 583K 2.8% 5 4 image2556 3288 rgb 3 8 jpeg no27 0 301 300 317K 1.3% ... ``` "rgb" is incorrect, which is evident after running: 'pdfimages -all -f 1 -l 1 grayscale-document.pdf foo && identify -format "%[type]" foo-000.jpg', which correctly outputs "Grayscale". Strangely, when "pdfimages -list" is fed a bilevel document, it states that every page has color "gray". To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/poppler/+bug/1916341/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] [NEW] rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
Public bug reported: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report file deletions when --remove-source-files is used. This is quite serious. People use --dry- run to see if an outcome will work as expected before a live run. When the simulated run shows *less* destruction than the live run, the consequences can be serious because rsync may unexpectedly destroy the only copy of a file. Users rely on --dry-run. Although users probably expect --dry-run to have limitations, we don't expect destructive operations to be under reported. If it were reversed, such that the live run were less destructive than the dry run, this wouldn't be as serious. Reproducer: $ mkdir -p /tmp/src /tmp/dest $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt $ cp /tmp/src/foo.txt /tmp/dest $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt foo.txt $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/ (no output) $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/ sender removed foo.txt $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt Note this bug is similar but differs in a few ways: https://bugzilla.samba.org/show_bug.cgi?id=3844 I've marked this as a security vulnerability because it causes unexpected data loss due to --dry-run creating a false expectation. ** Affects: rsync (Ubuntu) Importance: Undecided Status: New ** Information type changed from Private Security to Public -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to rsync in Ubuntu. https://bugs.launchpad.net/bugs/1925381 Title: rsync conceals file deletions from reporting when --dry-run --remove- source-files are used together Status in rsync package in Ubuntu: New Bug description: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report file deletions when --remove-source-files is used. This is quite serious. People use --dry-run to see if an outcome will work as expected before a live run. When the simulated run shows *less* destruction than the live run, the consequences can be serious because rsync may unexpectedly destroy the only copy of a file. Users rely on --dry-run. Although users probably expect --dry-run to have limitations, we don't expect destructive operations to be under reported. If it were reversed, such that the live run were less destructive than the dry run, this wouldn't be as serious. Reproducer: $ mkdir -p /tmp/src /tmp/dest $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt $ cp /tmp/src/foo.txt /tmp/dest $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt foo.txt $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/ (no output) $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/ sender removed foo.txt $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt Note this bug is similar but differs in a few ways: https://bugzilla.samba.org/show_bug.cgi?id=3844 I've marked this as a security vulnerability because it causes unexpected data loss due to --dry-run creating a false expectation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/1925381/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1925381] Re: rsync conceals file deletions from reporting when --dry-run --remove-source-files are used together
** Description changed: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report file deletions when --remove-source-files is used. This is quite serious. People use --dry- run to see if an outcome will work as expected before a live run. When the simulated run shows *less* destruction than the live run, the consequences can be serious because rsync may unexpectedly destroy the - only copy of a file. + only copy(*) of a file. Users rely on --dry-run. Although users probably expect --dry-run to have limitations, we don't expect destructive operations to be under reported. If it were reversed, such that the live run were less destructive than the dry run, this wouldn't be as serious. Reproducer: $ mkdir -p /tmp/src /tmp/dest $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt $ cp /tmp/src/foo.txt /tmp/dest $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt foo.txt $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/ (no output) $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/ sender removed foo.txt $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt + (*) note when I say it can destroy the only copy of a file, another + circumstance is needed: that is, rsync does not do a checksum by + default. It checks for identical files based on parameters like name + and date. So it's possible that two files match in the default + comparison but differ in the actual content. Losing a unique file in + this scenario is perhaps a rare corner case, but this bug should be + fixed nonetheless. + Note this bug is similar but differs in a few ways: https://bugzilla.samba.org/show_bug.cgi?id=3844 I've marked this as a security vulnerability because it causes unexpected data loss due to --dry-run creating a false expectation. ** Description changed: Rsync has an astonishing and dangerous bug: The dry run feature (-n / --dry-run) fails to report file deletions when --remove-source-files is used. This is quite serious. People use --dry- run to see if an outcome will work as expected before a live run. When the simulated run shows *less* destruction than the live run, the consequences can be serious because rsync may unexpectedly destroy the only copy(*) of a file. Users rely on --dry-run. Although users probably expect --dry-run to have limitations, we don't expect destructive operations to be under reported. If it were reversed, such that the live run were less destructive than the dry run, this wouldn't be as serious. Reproducer: $ mkdir -p /tmp/src /tmp/dest $ printf '%s\n' 'yada yada' > /tmp/src/foo.txt $ printf '%s\n' 'yada yada' > /tmp/src/bar.txt $ cp /tmp/src/foo.txt /tmp/dest $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt foo.txt $ rsync -na --info=remove1 --remove-source-files --existing src/* dest/ (no output) $ rsync -a --info=remove1 --remove-source-files --existing src/* dest/ sender removed foo.txt $ ls /tmp/src/ /tmp/dest/ /tmp/dest/: foo.txt /tmp/src/: bar.txt (*) note when I say it can destroy the only copy of a file, another circumstance is needed: that is, rsync does not do a checksum by - default. It checks for identical files based on parameters like name - and date. So it's possible that two files match in the default - comparison but differ in the actual content. Losing a unique file in - this scenario is perhaps a rare corner case, but this bug should be - fixed nonetheless. + default. It checks for identical files based on superficial parameters + like name and date. So it's possible that two files match in the + default superficial comparison but differ in the actual content. Losing + a unique file in this scenario is perhaps a rare corner case, but this + bug should be fixed nonetheless. Note this bug is similar but differs in a few ways: https://bugzilla.samba.org/show_bug.cgi?id=3844 I've marked this as a security vulnerability because it causes unexpected data loss due to --dry-run creating a false expectation. ** Description changed: Rsync has an astonishing and dangerous bug: - The dry run feature (-n / --dry-run) fails to report file deletions when - --remove-source-files is used. This is quite serious. People use --dry- - run to see if an outcome will work as expected before a live run. When - the simulated run shows *less* destruction than the live run, the - consequences can be serious because rsync may unexpectedly destroy the - only copy(*) of a file. + The dry run feature (-n / --dry-run) inhibits reporting of file + deletions when --remove-source-files is used. This is quite serious. + People use --dry-run to see if an outcome will work as expected before a + live run. When the simulated run shows *le
[Touch-packages] [Bug 1937082] [NEW] gunzip fails to extract data from stdin when the zip holds multiple files
Public bug reported: There is no good reason for this command to fail: $ wget --quiet -O - https://web.archive.org/web/20210721004028/freefontsdownload.net/download/76451/lucida_fax.zip | gunzip - The output is: [InternetShortcut] URL=HOMESITEfree-lucida_fax-font-76451.htmgzip: stdin has more than one entry--rest ignored What's happening is gzip logic has gotten tangled up with the gunzip logic. If gzip receives an input stream, it's sensible that the resulting archive contain just one file. But there's no reason gunzip should not be able to produce multiple files from a zip stream. Note that -c was not given to gunzip, so it should not have the constraints that use of stdout would impose. The man page is also a problem. The gunzip portion of the aggregated man page makes no statement about how stdin is expected to operate. At a minimum, it should say that a minus ("-") directs gunzip to read from stdin. ** Affects: gzip (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gzip in Ubuntu. https://bugs.launchpad.net/bugs/1937082 Title: gunzip fails to extract data from stdin when the zip holds multiple files Status in gzip package in Ubuntu: New Bug description: There is no good reason for this command to fail: $ wget --quiet -O - https://web.archive.org/web/20210721004028/freefontsdownload.net/download/76451/lucida_fax.zip | gunzip - The output is: [InternetShortcut] URL=HOMESITEfree-lucida_fax-font-76451.htmgzip: stdin has more than one entry--rest ignored What's happening is gzip logic has gotten tangled up with the gunzip logic. If gzip receives an input stream, it's sensible that the resulting archive contain just one file. But there's no reason gunzip should not be able to produce multiple files from a zip stream. Note that -c was not given to gunzip, so it should not have the constraints that use of stdout would impose. The man page is also a problem. The gunzip portion of the aggregated man page makes no statement about how stdin is expected to operate. At a minimum, it should say that a minus ("-") directs gunzip to read from stdin. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gzip/+bug/1937082/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937850] [NEW] the -L / --relative option breaks --accept-regex
Public bug reported: This code should in principle (per the docs) fetch a few *.pdf files: $ wget -r --level 1 --adjust-extension --relative --no-clobber --no-directories\ --domains=ncua.gov --accept-regex 'administrative-orders/.*.pdf'\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=22&sort=year&dir=desc&sq=' But it misses all *.pdf files. When the --relative option is removed, the PDF files are downloaded. However, when you examine the tree-top HTML file, the links pointing to PDF files actually are relative. ** Affects: wget (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1937850 Title: the -L / --relative option breaks --accept-regex Status in wget package in Ubuntu: New Bug description: This code should in principle (per the docs) fetch a few *.pdf files: $ wget -r --level 1 --adjust-extension --relative --no-clobber --no-directories\ --domains=ncua.gov --accept-regex 'administrative-orders/.*.pdf'\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=22&sort=year&dir=desc&sq=' But it misses all *.pdf files. When the --relative option is removed, the PDF files are downloaded. However, when you examine the tree-top HTML file, the links pointing to PDF files actually are relative. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1937850/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1937874] [NEW] one --accept-regex expression negates another
Public bug reported: This command should theoretically fetch all PDFs on a page: $ wget -v -d -r --level 1 --adjust-extension --no-clobber --no-directories\ --accept-regex 'administrative-orders/.*/administrative-order-matter-'\ --accept-regex 'administrative-orders.*.pdf'\ --accept-regex 'administrative-orders.page[^&]*$'\ --directory-prefix=/tmp\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=56' But it fails to grab any of them, giving the output: --- Deciding whether to enqueue "https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf";. https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf is excluded/not-included through regex. Decided NOT to load it. --- That's bogus. The workaround is to remove this option: --accept-regex 'administrative-orders.page[^&]*$' But that should not be necessary. Adding an --accept-* clause should never cause another --accept-* clause to become invalidated and it should not shrink the set of fetched files. ** Affects: wget (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to wget in Ubuntu. https://bugs.launchpad.net/bugs/1937874 Title: one --accept-regex expression negates another Status in wget package in Ubuntu: New Bug description: This command should theoretically fetch all PDFs on a page: $ wget -v -d -r --level 1 --adjust-extension --no-clobber --no-directories\ --accept-regex 'administrative-orders/.*/administrative-order-matter-'\ --accept-regex 'administrative-orders.*.pdf'\ --accept-regex 'administrative-orders.page[^&]*$'\ --directory-prefix=/tmp\ 'https://www.ncua.gov/regulation-supervision/enforcement-actions/administrative-orders?page=56' But it fails to grab any of them, giving the output: --- Deciding whether to enqueue "https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf";. https://www.ncua.gov/files/administrative-orders/AO14-0241-R4.pdf is excluded/not-included through regex. Decided NOT to load it. --- That's bogus. The workaround is to remove this option: --accept-regex 'administrative-orders.page[^&]*$' But that should not be necessary. Adding an --accept-* clause should never cause another --accept-* clause to become invalidated and it should not shrink the set of fetched files. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/1937874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1940691] [NEW] sfdisk fails to overwrite disks that contain a pre-existing linux partition
Public bug reported: This command should non-interactively obliterate whatever partition table is on /dev/sde, and create a new table with a linux partition that spans the whole disk: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Sometimes it works correctly; sometimes not. It seems to work correctly as long as the pre-existing partition table does not already contain a linux partition. E.g. if the existing table just contains an exFAT partition, there's no issue. But if there is a linux partition, it gives this output: - Old situation: Device StartEndSectors Size Type /dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64) >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. - sfdisk should *always* overwrite the target disk unconditionally. This is what the dump of the target drive looks like in the failure case: $ sfdisk -d /dev/sdd label: gpt label-id: device: /dev/sdd unit: sectors first-lba: 34 last-lba: 1953525134 grain: 33553920 sector-size: 512 /dev/sdd1 : start=2048, size= 1953523087, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=, name="Linux x86-64 root (/)" $ sfdisk -v sfdisk from util-linux 2.36.1 Even the workaround is broken. That is, running the following: $ wipefs -a /dev/sde should put the disk in a state that can be overwritten. But whatever residual metadata it leaves behind still triggers the sfdisk bug: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Checking that no-one is using this disk right now ... OK Disk /dev/sde: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Disk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. Workaround 2 (also fails): $ dd if=/dev/zero of=/dev/sde bs=1M count=512 $ sfdisk -d /dev/sde sfdisk: /dev/sde: does not contain a recognized partition table ^ the nuclear option did the right thing, but sfdisk still fails to partition the drive (same error). The *only* workaround that works is an interactive partitioning with gdisk. ** Affects: util-linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1940691 Title: sfdisk fails to overwrite disks that contain a pre-existing linux partition Status in util-linux package in Ubuntu: New Bug description: This command should non-interactively obliterate whatever partition table is on /dev/sde, and create a new table with a linux partition that spans the whole disk: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Sometimes it works correctly; sometimes not. It seems to work correctly as long as the pre-existing partition table does not already contain a linux partition. E.g. if the existing table just contains an exFAT partition, there's no issue. But if there is a linux partition, it gives this output: - Old situation: Device StartEndSectors Size Type /dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64) >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. - sfdisk should *always* overwrite the target disk unconditionally. This is what the dump of the target drive looks like in the failure case: $ sfdisk -d /dev/sdd label: gpt label-id: device: /dev/sdd unit: sectors first-lba: 34 last-lba: 1953525134 grain: 33553920 sector-size: 512 /dev/sdd1 : start=2048, size= 1953523087, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=, name="Linux x86-64 root (/)" $ sfdisk -v sfdisk from util-linux 2.36.1 Even the workaround is broken. That is, running the following: $ wipefs -a /dev/sde should put the disk in a state that can be overwritten. But whatever residual metadata it leaves behind still triggers the sfdisk bug: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Checking that no-one is using this disk right now ... OK Disk /dev/sde: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors Disk model: Disk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal
[Touch-packages] [Bug 1940691] Re: sfdisk fails to overwrite disks that contain a pre-existing linux partition
** Description changed: This command should non-interactively obliterate whatever partition table is on /dev/sde, and create a new table with a linux partition that spans the whole disk: - $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label + $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Sometimes it works correctly; sometimes not. It seems to work correctly as long as the pre-existing partition table does not already contain a linux partition. E.g. if the existing table just contains an exFAT partition, there's no issue. But if there is a linux partition, it gives this output: - Old situation: Device StartEndSectors Size Type /dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64) >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. - sfdisk should *always* overwrite the target disk unconditionally. This is what the dump of the target drive looks like in the failure case: $ sfdisk -d /dev/sdd label: gpt label-id: device: /dev/sdd unit: sectors first-lba: 34 last-lba: 1953525134 grain: 33553920 sector-size: 512 /dev/sdd1 : start=2048, size= 1953523087, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=, name="Linux x86-64 root (/)" $ sfdisk -v sfdisk from util-linux 2.36.1 Even the workaround is broken. That is, running the following: $ wipefs -a /dev/sde should put the disk in a state that can be overwritten. But whatever residual metadata it leaves behind still triggers the sfdisk bug: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Checking that no-one is using this disk right now ... OK Disk /dev/sde: 931.51 GiB, 1000204886016 bytes, 1953525168 sectors - Disk model: Disk + Disk model: Disk Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 4096 bytes / 33553920 bytes >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. + + Workaround 2 (also fails): + + $ dd if=/dev/zero of=/dev/sde bs=1M count=512 + + $ sfdisk -d /dev/sde + sfdisk: /dev/sde: does not contain a recognized partition table + + ^ the nuclear option did the right thing, but sfdisk still fails to + partition the drive (same error). + + The *only* workaround that works is an interactive partitioning with + gdisk. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux in Ubuntu. https://bugs.launchpad.net/bugs/1940691 Title: sfdisk fails to overwrite disks that contain a pre-existing linux partition Status in util-linux package in Ubuntu: New Bug description: This command should non-interactively obliterate whatever partition table is on /dev/sde, and create a new table with a linux partition that spans the whole disk: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Sometimes it works correctly; sometimes not. It seems to work correctly as long as the pre-existing partition table does not already contain a linux partition. E.g. if the existing table just contains an exFAT partition, there's no issue. But if there is a linux partition, it gives this output: - Old situation: Device StartEndSectors Size Type /dev/sde1 2048 1953525134 1953523087 931.5G Linux root (x86-64) >>> Created a new GPT disklabel (GUID: ). /dev/sde1: Sector 2048 already used. Failed to add #1 partition: Numerical result out of range Leaving. - sfdisk should *always* overwrite the target disk unconditionally. This is what the dump of the target drive looks like in the failure case: $ sfdisk -d /dev/sdd label: gpt label-id: device: /dev/sdd unit: sectors first-lba: 34 last-lba: 1953525134 grain: 33553920 sector-size: 512 /dev/sdd1 : start=2048, size= 1953523087, type=4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709, uuid=, name="Linux x86-64 root (/)" $ sfdisk -v sfdisk from util-linux 2.36.1 Even the workaround is broken. That is, running the following: $ wipefs -a /dev/sde should put the disk in a state that can be overwritten. But whatever residual metadata it leaves behind still triggers the sfdisk bug: $ sfdisk --label gpt /dev/sde <<< 'start=2048, type='"$(sfdisk --label gpt -T | awk '{IGNORECASE = 1;} /linux filesystem/{print $1}')" Checking that no-one is using this disk right now ... OK Disk /dev/sde: 931.51 GiB
[Touch-packages] [Bug 1890654] Re: udev service does not log
Sorry, i mean to say /var/log/syslog (not /var/log/system) shows the device was attached. The verbosity in /var/log/syslog increases when udev_log=debug, but still no /var/log/udev. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890654 Title: udev service does not log Status in systemd package in Ubuntu: New Bug description: By default udev is supposed to log to /var/log. In Ubuntu 20 it is not logging. Logging was then explicitly enabled by uncommenting this line in /etc/udev/udev.conf: "udev_log=info" After running "systemctl restart udev" and plugging in a USB drive, there is still no udev log in /var/log. Yet /var/log/system shows that a device was in fact attached. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890654/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890827] [NEW] udev and udevadm documentation missing
Public bug reported: The man page for udevadm neglects to mention options which seem to only be documented in stackexchange. E.g. udevadm monitor --environment udevadm control --reload-rules >From the man page, it's unclear what the difference is between /udevadm trigger/ and /udevadm test/. The description should tell the user enough to work out which one they need to use for a certain situation. E.g. I wrote a new rule and it's not triggering. Is the trigger command or the test command suitable for diagnosing the problem? The documentation in /usr/share/doc/udev/ is strangely specific to some esoteric network interface naming. There is no basic description of what udev's purpose is or what its capabilities are. One of the most notable tasks is to react to the insertion of USB drives, and there is no mention of this. The /etc/fstab table also has a role in mounting USB drives, but there is no mention as to how udev works with /etc/fstab. I've found that if I remove a line in /etc/fstab and attach the drive pertaining to that line, it gets mounted anyway. If the fstab file supercedes udev, then this should be mentioned in the documentation. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890827 Title: udev and udevadm documentation missing Status in systemd package in Ubuntu: New Bug description: The man page for udevadm neglects to mention options which seem to only be documented in stackexchange. E.g. udevadm monitor --environment udevadm control --reload-rules From the man page, it's unclear what the difference is between /udevadm trigger/ and /udevadm test/. The description should tell the user enough to work out which one they need to use for a certain situation. E.g. I wrote a new rule and it's not triggering. Is the trigger command or the test command suitable for diagnosing the problem? The documentation in /usr/share/doc/udev/ is strangely specific to some esoteric network interface naming. There is no basic description of what udev's purpose is or what its capabilities are. One of the most notable tasks is to react to the insertion of USB drives, and there is no mention of this. The /etc/fstab table also has a role in mounting USB drives, but there is no mention as to how udev works with /etc/fstab. I've found that if I remove a line in /etc/fstab and attach the drive pertaining to that line, it gets mounted anyway. If the fstab file supercedes udev, then this should be mentioned in the documentation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890827/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890520] Re: catastrophic bug with deluser command -- destroys large number of system files
Notice also there is a serious transparency problem. The output only shows files for which removal failed. This acutely heightens the destruction because it potentially destroyed *thousands* of files as I sat there and let it run. The tool gives no idea how what's being destroyed. The admin has to trust that their understanding of the scope of removal is accurate. In the absence of errors, an admin would let it run through to the end, resulting in maximum damage. This tool badly needs a --simulate option. And regardless of simulation, it should show what files are affected. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to adduser in Ubuntu. https://bugs.launchpad.net/bugs/1890520 Title: catastrophic bug with deluser command -- destroys large number of system files Status in adduser package in Ubuntu: New Bug description: I installed rygel and created a specific rygel user to run it with (as directed by the docs). I then realized a specific user was not needed. To reverse my steps, I ran deluser which proceeded to delete lots of files that have nothing to do with the rygel user: root@host:~# adduser --home /home/rygel --disabled-password --disabled-login --gecos 'Rygel media server' rygel root@host:~# sudo su - rygel rygel@host:$ systemctl start rygel rygel@host:$ exit root@host:~# deluser --remove-home --remove-all-files rygel Looking for files to backup/remove ... /usr/sbin/deluser: Cannot handle special file /etc/systemd/system/mdm.service /usr/sbin/deluser: Cannot handle special file /etc/systemd/system/samba-ad-dc.service /usr/sbin/deluser: Cannot handle special file /etc/systemd/system/cgmanager.service /usr/sbin/deluser: Cannot handle special file /etc/systemd/system/cgproxy.service /usr/sbin/deluser: Cannot handle special file /dev/vcsa7 /usr/sbin/deluser: Cannot handle special file /dev/vcsu7 /usr/sbin/deluser: Cannot handle special file /dev/vcs7 /usr/sbin/deluser: Cannot handle special file /dev/gpiochip0 /usr/sbin/deluser: Cannot handle special file /dev/dvdrw /usr/sbin/deluser: Cannot handle special file /dev/dvd /usr/sbin/deluser: Cannot handle special file /dev/cdrw /usr/sbin/deluser: Cannot handle special file /dev/zfs /usr/sbin/deluser: Cannot handle special file /dev/vhost-vsock /usr/sbin/deluser: Cannot handle special file /dev/vhost-net /usr/sbin/deluser: Cannot handle special file /dev/uhid /usr/sbin/deluser: Cannot handle special file /dev/vhci /usr/sbin/deluser: Cannot handle special file /dev/userio /usr/sbin/deluser: Cannot handle special file /dev/nvram /usr/sbin/deluser: Cannot handle special file /dev/btrfs-control /usr/sbin/deluser: Cannot handle special file /dev/cuse /usr/sbin/deluser: Cannot handle special file /dev/autofs /usr/sbin/deluser: Cannot handle special file /dev/sde /usr/sbin/deluser: Cannot handle special file /dev/sdd /usr/sbin/deluser: Cannot handle special file /dev/sdc /usr/sbin/deluser: Cannot handle special file /dev/sdb /usr/sbin/deluser: Cannot handle special file /dev/sg5 /usr/sbin/deluser: Cannot handle special file /dev/sg4 /usr/sbin/deluser: Cannot handle special file /dev/sg3 /usr/sbin/deluser: Cannot handle special file /dev/sg2 /usr/sbin/deluser: Cannot handle special file /dev/vcsa6 /usr/sbin/deluser: Cannot handle special file /dev/vcsu6 /usr/sbin/deluser: Cannot handle special file /dev/vcs6 /usr/sbin/deluser: Cannot handle special file /dev/vcsa5 /usr/sbin/deluser: Cannot handle special file /dev/vcsu5 /usr/sbin/deluser: Cannot handle special file /dev/vcs5 /usr/sbin/deluser: Cannot handle special file /dev/vcsa4 /usr/sbin/deluser: Cannot handle special file /dev/vcsu4 /usr/sbin/deluser: Cannot handle special file /dev/vcs4 /usr/sbin/deluser: Cannot handle special file /dev/vcsa3 /usr/sbin/deluser: Cannot handle special file /dev/vcsu3 /usr/sbin/deluser: Cannot handle special file /dev/vcs3 /usr/sbin/deluser: Cannot handle special file /dev/vcsa2 /usr/sbin/deluser: Cannot handle special file /dev/vcsu2 /usr/sbin/deluser: Cannot handle special file /dev/vcs2 /usr/sbin/deluser: Cannot handle special file /dev/hidraw2 /usr/sbin/deluser: Cannot handle special file /dev/hidraw1 /usr/sbin/deluser: Cannot handle special file /dev/cdrom /usr/sbin/deluser: Cannot handle special file /dev/hidraw0 /usr/sbin/deluser: Cannot handle special file /dev/fb0 /usr/sbin/deluser: Cannot handle special file /dev/i2c-5 /usr/sbin/deluser: Cannot handle special file /dev/i2c-4 /usr/sbin/deluser: Cannot handle special file /dev/i2c-3 /usr/sbin/deluser: Cannot handle special file /dev/i2c-2 /usr/sbin/deluser: Cannot handle special file /dev/i2c-1 /usr/sbin/deluser: Cannot handle special file /dev/i2c-0 /usr/sbin/deluser: Cannot handle special file /dev/rtc /usr/sbin/deluser: Cannot handle special file /dev/stderr /usr/sbin/deluser: Cannot handle s
[Touch-packages] [Bug 1890836] [NEW] udev rule read but "RUN" command is not executed
Public bug reported: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890836 Title: udev rule read but "RUN" command is not executed Status in systemd package in Ubuntu: New Bug description: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890836] Re: udev rule read but "RUN" command is not executed
It fails for me on two different systems: * Ubuntu 20.04 (Focal) * Linux Mint 19.2 (Tina, which is based on Bionic) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890836 Title: udev rule read but "RUN" command is not executed Status in systemd package in Ubuntu: Incomplete Bug description: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890836] Re: udev rule read but "RUN" command is not executed
It turns out the problem arises out of cargo cult programming on my part. The bang in KERNEL=="sd*[!0-9]" is what I copied out of stackexchange, and it's exactly what prevents the mount from matching. I suspected that early on, but ruled it out because when the device first connects it must connect as /dev/sda (as the partition table must be read before there can be an sda1). Now I'm figuring the sda gets replaced with sda1 before it reaches my custom rule. In any case, the bug is not as I reported. I'm sorry this turned out to be a non-bug and I'm sorry I wasted your time Mr. Streetman. This can be closed. I may open a new bug report to improve the debug output, because we shouldn't have to work in the dark and guess about what the matching criteria is doing. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890836 Title: udev rule read but "RUN" command is not executed Status in systemd package in Ubuntu: Invalid Bug description: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890836] Re: udev rule read but "RUN" command is not executed
PEBKAC ** Changed in: systemd (Ubuntu) Status: Incomplete => Invalid ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Bill Yikes (yik3s) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890836 Title: udev rule read but "RUN" command is not executed Status in systemd package in Ubuntu: Invalid Bug description: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890890] [NEW] more debugging verbosity for udev rules needed
Public bug reported: I wrote a udev rule that would not trigger when expected. I spent 2 days working on it, trying to understand what the problem was. I finally figured it out -- it was a matching problem: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836 The most verbose output possible is with the log level set to "debug". This level of logging does not show users what criteria is being checked and what the result is. So users are working in the dark. We have to guess what udev is doing. And we're bad at it, because if we could guess correctly we probably would have written the rule correctly in the first place. Consider procmail. This is an application where users write rules that contain matching criteria. When Procmail doesn't work as expected, the logs show in detail what criteria matches and what does not. This is what udev needs. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890890 Title: more debugging verbosity for udev rules needed Status in systemd package in Ubuntu: New Bug description: I wrote a udev rule that would not trigger when expected. I spent 2 days working on it, trying to understand what the problem was. I finally figured it out -- it was a matching problem: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836 The most verbose output possible is with the log level set to "debug". This level of logging does not show users what criteria is being checked and what the result is. So users are working in the dark. We have to guess what udev is doing. And we're bad at it, because if we could guess correctly we probably would have written the rule correctly in the first place. Consider procmail. This is an application where users write rules that contain matching criteria. When Procmail doesn't work as expected, the logs show in detail what criteria matches and what does not. This is what udev needs. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890890/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1890836] Re: udev rule read but "RUN" command is not executed
Bug report to improve debugging output: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890890 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1890836 Title: udev rule read but "RUN" command is not executed Status in systemd package in Ubuntu: Invalid Bug description: The following was introduced as "/etc/udev/rules.d/99-harvest_camera.rules": ACTION=="add", KERNEL=="sd*[!0-9]", ENV{ID_FS_UUID_ENC}=="C355-A42D", RUN+="/usr/bin/sudo -u bill /home/bill/scripts/harvest_camera.sh" When the device is attached, it gets mounted but the harvest_camera.sh script does not execute. The udev_log=debug parameter is set in /etc/udev/udev.conf. Verbosity was also maximized by running "udevadm control --log-priority=debug". After running "udevadm monitor --environment --udev", the drive was attached. The output shows a device being created (/dev/sda1) and the UUID in the rule matches. But the script simply never executes. The /var/log/syslog file shows: " Reading rules file: /etc/udev/rules.d/99-harvest_camera.rules Successfully forked off 'n/a' as PID 2201. 1-2.3: Worker [2201] is forced for rocessing SEQNUM=7973. " So the logs make it look as though the script was executed. The script is simply a stub that does a "touch /tmp/IhaveExecuted" and a call to zenity to give a popup announcement. But none of that happens (no popup and no new file in /tmp/). With maximum verbosity, there is no way to further diagnose this. Deeper detail is needed that shows which matching criteria in the rules is being tried and what the result is. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1890836/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 910272] Re: USB->Parallel adapter produces crappy device URI and CUPS "usb" backend cannot cope with it
Same problem for me. I have an old parallel-only printer. It has been working with a dedicated printer server, but the printer server died and the PC has no parallel port. So I connected a USB-to-LPT cable. As I attach the cable /var/log/syslog shows: parport0: fix this legacy no-device port driver! lp0: using parport0 (polling) There does not exist a /dev/usb/lp0. I still set "DeviceURI parallel:/dev/usb/lp0" since that is what the instructions still say (https://wiki.ubuntu.com/DebuggingPrintingProblems#USB_-.3E_Parallel_adapter), and indeed that fails. I also tried "DeviceURI parallel:/dev/parport0" and CUPS rejected it. Then I tried "DeviceURI parallel:/dev/lp0". CUPS accepted it, I sent a test print, and it just sits on the job queue with the msg "Printer not connected; will retry in 30 seconds". # usb_printerid /dev/lp0 Error: Invalid argument: GET_DEVICE_ID on '/dev/lp0' # usb_printerid /dev/parport0 Error: Invalid argument: GET_DEVICE_ID on '/dev/parport0' At another moment, I got a different error: # usb_printerid /dev/lp0 Error: Device or resource busy: can't open '/dev/lp0' This is on Bionic. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/910272 Title: USB->Parallel adapter produces crappy device URI and CUPS "usb" backend cannot cope with it Status in cups package in Ubuntu: Fix Released Status in cups source package in Oneiric: Won't Fix Bug description: Parallel port dot matrix printer Panasonic KX-P2124 connected via usb- parallel cable to HP6600 PC; running Ubuntu 11.10 system located on external hard drive attached by usb. Worked on Ubuntu version 8 using URI "parallel:/dev/usb/lp0". Understand that usblp has been deprecated; replace with ??? Cups reports printer not connected. CUPS version is (from UbuntuSoftwareCenter) - "cups 1.5.0-8ubuntu6". #Researched existing bugs - lots of info - no results. No "Help" menu found by selecting upper right located "Gear"/"Printers; could not find any "Wizard." Thank you for your assistance, nvsoar w8@w8-FJ463AAR-ABA-a6528p:~$ uname -a Linux w8-FJ463AAR-ABA-a6528p 3.0.0-15-generic #24-Ubuntu SMP Mon Dec 12 15:25:25 UTC 2011 i686 i686 i386 GNU/Linux w8@w8-FJ463AAR-ABA-a6528p:~$ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 067b:3507 Prolific Technology, Inc. PL3507 ATAPI6 Bridge Bus 001 Device 004: ID 058f:6377 Alcor Micro Corp. Multimedia Card Reader Bus 002 Device 002: ID 050d:0002 Belkin Components #Device immediately above is usb to parallel cable w8@w8-FJ463AAR-ABA-a6528p:~$ lsmod | grep lp lp 17455 0 parport40930 4 parport_pc,ppdev,uss720,lp w8@w8-FJ463AAR-ABA-a6528p:~$ lsmod | grep ppdev ppdev 12849 0 parport40930 4 parport_pc,ppdev,uss720,lp w8@w8-FJ463AAR-ABA-a6528p:~$ lsmod | grep parport_pc parport_pc 32114 0 parport40930 4 parport_pc,ppdev,uss720,lp w8@w8-FJ463AAR-ABA-a6528p:~$ ls -l /dev/usb/lp* /dev/bus/usb/*/* ls: cannot access /dev/usb/lp*: No such file or directory crw-rw-r-- 1 root root 189, 0 2011-12-30 15:04 /dev/bus/usb/001/001 crw-rw-r-- 1 root root 189, 1 2011-12-30 15:04 /dev/bus/usb/001/002 crw-rw-r-- 1 root root 189, 3 2011-12-30 15:04 /dev/bus/usb/001/004 crw-rw-r-- 1 root root 189, 128 2011-12-30 15:04 /dev/bus/usb/002/001 crw-rw-r-- 1 root lp 189, 129 2011-12-30 15:25 /dev/bus/usb/002/002 w8@w8-FJ463AAR-ABA-a6528p:~$ dmesg | grep par [0.00] Booting paravirtualized kernel on bare hardware [0.00] vt handoff: transparent VT on vt#7 [0.210399] hpet0: 3 comparators, 32-bit 25.00 MHz counter [ 28.754567] uss720: protocols (eg. bitbang) over USS720 usb to parallel cables [ 28.893725] type=1400 audit(1325286282.534:2): apparmor="STATUS" operation="profile_load" name="/sbin/dhclient" pid=705 comm="apparmor_parser" [ 28.893736] type=1400 audit(1325286282.534:3): apparmor="STATUS" operation="profile_replace" name="/sbin/dhclient" pid=755 comm="apparmor_parser" [ 28.894175] type=1400 audit(1325286282.534:4): apparmor="STATUS" operation="profile_load" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=755 comm="apparmor_parser" [ 28.894324] type=1400 audit(1325286282.534:5): apparmor="STATUS" operation="profile_replace" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=705 comm="apparmor_parser" [ 28.894438] type=1400 audit(1325286282.534:6): apparmor="STATUS" operation="profile_load" name="/usr/lib/connman/scripts/dhclient-script" pid=755 comm="apparmor_parser" [ 28.894592] type=1400 audit(1325286282.534:7): apparmor="STATUS" operation="profile_replace" name="/usr/l