Re: Proper handling of Lintian warnings due to other packages
* Scott Talbert: " Re: Proper handling of Lintian warnings due to other packages" (Wed, 31 Jan 2024 13:16:11 -0500 (EST)): > On Wed, 31 Jan 2024, Jonas Smedegaard wrote: > > > Quoting Scott Talbert (2024-01-31 16:49:59) > >> On Wed, 31 Jan 2024, Jonas Smedegaard wrote: > >> > >>> Unfortunately it is not likely that the package will be catch up soon, > >>> because the Haskell team upgrade most Haskell libraries only as a whole. > >>> > >>> That issue is not tracked in debbugs, because those vocal in the Haskell > >>> team actively discourages the use of debbugs: > >>> https://lists.debian.org/debian-haskell/2024/01/msg00012.html > >> > >> Note: I don't discourage usage of debbugs. It's just that I'm unlikely to > >> notice bugs immediately due to the way debbugs notifications work. > > > > The net effect of a) silence in response to filing bugreports, b) > > responses when reporting issues to Haskell mailinglist, and even c) you > > [dissing] my explicit attempts at steering conversation to the > > bugtracker is discouragement of using the bugtracker. > > > > - Jonas > > > > [dissing]: Sorry, I cannot find any other way to describe what you > > did when you replied to the list when I posted > > https://lists.debian.org/debian-haskell/2024/01/msg3.html and wrote > > "Meh" when I posted > > https://lists.debian.org/debian-haskell/2024/01/msg00010.html > > With respect to "silence in response to filing bug reports": Debian is a > volunteer project. There is no service level agreement for bug response > time, or expectation even that a bug will ever get responded to. This is for sure correct while indeed you are raising expectations that a bug handled via mailing lists will get more attention. > My "meh" was in response to you insisting that the conversation be moved > to the bug tracker. I was explicitly stating that I was okay with > discussing bugs on the mailing list and NOT insisting that they be moved > to the bug tracker. The bug tracker is not user friendly for some users, > so I personally am fine with receiving reports through other means and > will not insist everyone use the BTS. I heard the same (missing user friendliness) about mailing lists, there will always be someone to prefer one communication over the other. I think it is more appropriate to face the fact what we have in Debian to track bugs, and just now this is the BTS. The integration with release management (e.g. RFC bugs preventing a package to migrate to testing etc.) is substantial, a feature you don't have with mailing lists. BTW I don't see the significant difference between answering a mail from a mailing list or answering a mail from the BTS. If it is about information via mailing list: wouldn't X-Debbugs-Cc: be an appropriate solution to forward bugs to the mailing list? Best Mathias -- Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6 pgpevh7DMVgFS.pgp Description: Digitale Signatur von OpenPGP
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
On 2024-02-01, Carsten Schoenert wrote: > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time > stamps from the emails)? > I as the uploader for libcoap have no chance to do any action on this > bug report! This behavior I'm not expecting within Debian. > What are the plans now with forwarding the underlying issue to upstream? > Upstream is very responsive and I've good contacts to the upstream > authors, but who is doing this work now? I'm mostly a bystander here. But there is no underlying issue to forward to upstream. Ex. The debian toolchain has been changed on most 32bit architectures to produce different code if time-related types are involved. This involves doing a giant library transition involving a 4 digit number of source packages, and it will while the transition is ongoing, be a *nightmare* of crashes for anyone with a machine on one of the involved 32bit architectures, so it need to happen in a very short timeframe. We should just be happy that there is at least 4 people working in shifts around the clock trying to get this done in less than a week of calendar time. /Sune
Re: Proper handling of Lintian warnings due to other packages
On Wed, 2024-01-31 at 10:49 -0500, Scott Talbert wrote: > > Note: I don't discourage usage of debbugs. It's just that I'm unlikely to > notice bugs immediately due to the way debbugs notifications work. You should be able to use tracker.debian.org to subscribe to teams or individual packages which you are interested in, which includes an option for receiving BTS traffic. Ian.
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
On Thu, Feb 01, 2024 at 07:45:57AM +0100, Carsten Schoenert wrote: > Hello Steve, > Am 31.01.24 um 21:59 schrieb Steve Langasek: > ... > > Please find the patch for this NMU attached. > > If you have any concerns about this patch, please reach out ASAP. > ^^ > > Although > > this package will be uploaded to experimental immediately, there will be a > > period of several days before we begin uploads to unstable; so if > > information > > becomes available that your package should not be included in the > > transition, > > there is time for us to amend the planned uploads. > I'm a bit puzzled and disappointed. > libcopap3 isn't a package that is within the QA group nor is it bit rotting. > What is the rationale behind rising a bug report at 9:51pm my time and > firing a *direct* NMU upload just 11min later (according to the time stamps > from the emails)? There are 1200+ source packages that require NMUing and the Debian archive is a moving target. In the past 3 days the list of packages requiring uploads has been regenerated 3 times with changes each time due to archive removals, new sonames in unstable, etc. Churning through the list of 1200 packages is at this rate going to take at least a week (after 4 days we've gotten bugs filed and NMUs to experimental completed for less than 400 of the 1200 packages). It is not practical to leave a gap of any significant length of time between the filing of bugs in patches and the uploads to experimental. There will be a pause between the uploads to experimental, and the uploads to unstable, which gives space for maintainer feedback while we run analysis against the contents of experimental with regards to usrmerge. > I as the uploader for libcoap have no chance to do any action on this bug > report! This behavior I'm not expecting within Debian. > What are the plans now with forwarding the underlying issue to upstream? > Upstream is very responsive and I've good contacts to the upstream authors, > but who is doing this work now? This is an ABI change resulting from a change to compiler flags. You will see the diff includes no changes to upstream source. There is nothing to forward. > I read the wiki page mentioned from the initial email again, also there I > can't find a written plan that would explain me why the bug reporting > together with a direct upload did happen. I see no plan there what will > happen on what time. > Why no usual muss bug filling did happen so groups and maintainers would > have some knowledge about these planned changes? BTW: I've no problem with > the technical thing what is happen, but I need to deal also with other > things too like a CVE fix for libcopa3. Since this has only been uploaded to experimental, I would expect this does not interfere with your CVE handling? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Transparency into private keys of Debian
Hi I'm exploring how to defend against an attacker who can create valid signatures for cryptographic private keys (e.g., PGP) that users need to trust when using an operating system such as Debian. A signature like that can be used in a targetted attacks against one victim. For example, apt does not have any protection against this threat scenario, and often unprotected ftp:// or http:// transports are used, which are easy to man-in-the-middle. Even with https:// there is a large number of mirror sites out there that can replace content you get. There is a risk that use of a compromised trusted apt PGP key will not be noticed. Attackers are also in a good position to deny themselves out of their actions if they are careful. Part of my effort is to inventory all trusted private keys that a distribution needs to manage on their own, or depend on that are managed by others, and gain some insight how these keys are handled. Does the Debian project, or any members, publish information on these topics? Has this been discussed before? Some questions that I think would be useful to answer include: 1) List of relevant private keys, held by the organization, its members, or someone else. As far as I can tell from Debian, the list includes the following PGP trust anchors: B8B8 0B5B 623E AB6A D877 5C45 B7C5 D7D6 3509 47F8 05AB 9034 0C0C 5E79 7F44 A8C8 254C F3B5 AEC0 A8F0 4D64 FEC1 19C2 0290 67D6 E791 F8D2 585B 8783 D481 1F89 983E 0081 FDE0 18F3 CC96 73A4 F27B 8DD4 7936 AC53 0D52 0F2F 3269 F5E9 8313 A484 4904 4AAD 5C5D A428 5295 FC7B 1A81 6000 62A9 605C 66F0 0D6C 9793 80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE 5E61 B217 265D A980 7A23 C5FF 4DFA B270 CAA9 6DFA 6D33 866E DD8F FA41 C014 3AED DCC9 EFBF 77E1 1517 Compromising any single key on this list leads to trouble. However I don't think this list is complete. What other keys are there? I believe there are keys used to sign some component of the boot phase, compare the 'shim-signed' and 'grub-efi-amd64-signed' packages. What private keys held by Debian are involved here? What keys held by others are involved? What other similar packages exists? 2) For each private key, information about its management and lifecycle. Relevant questions include: a) How was the key generated? By whom? On what hardware? What software? In what environment? What legal jurisdiction apply to people involved? b) How is the key stored and protected during its lifetime? What media is used? Who control the physical storage of the key? How are they stored and transported? What jurisdiction? c) Under what policy is the key used? What should it sign? Who authorize the signing? What hardware and software is used? What jurisdiction? d) For externally held keys, what are the legal terms we use the keys under? What insight into key transparency questions do we have? What of those can we make public? How do they restrict what we are allowed to do? 3) Which less visible private keys are indirectly trusted by users of the distribution? For example, all DD PGP keys are indirectly trusted since they are permitted to make uploads into the archive. Host keys used to authorized access to sensitive systems may also be relevant. I'm primarily thinking SSH private keys to a system that may have online access to a private key signing oracle. Indirectly, questions about authentication protocols and authorization methods are relevant. To the extent that symmetric shared secrets (rather than asymmetric public/private keys) are involved, the same question applies. Other aspects worth exploring? I understand commercial distributions have different incentives related to making this information public. They have a commercial interest to defend, and has usually entered various legal arrangements that create obstacles related to releasing information. As we've seen with the WebPKI CA business, that model does not inspire trust and leads to systematic failures. More transparent approaches like Certificate Transparency and LetsEncrypt evolved as a consequence. I believe that Debian is in a good position to improve things and, if there is interest, could lead the way by documenting a better approach, and describe how to deal with these concerns in a more transparent way than what we do today. Thoughts? /Simon signature.asc Description: PGP signature
Bug#1062414: ITP: iraf-xdimsum -- Deep Infrared Mosaicing Software for IRAF
Package: wnpp Severity: wishlist Owner: Ole Streicher X-Debbugs-Cc: debian-as...@lists.debian.org, debian-devel@lists.debian.org * Package name: iraf-xdimsum Version : 2003.01.24 Upstream Author : NOAO * URL : https://github.com/iraf-community/iraf-xdimsum * License : IRAF Programming Lang: IRAF SPP Description : Deep Infrared Mosaicing Software for IRAF XDIMSUM is a package for creating accurate sky subtracted images from sets of dithered observations. While the observations need not be in the infrared, the dominance of the variable sky background in infrared data requires the dithering and recombination of many short carefully sky subtracted exposures to produce deep images. I will maintain it within the Debian Astro team. A git repository was created at https://salsa.debian.org/debian-astro-team/iraf-xdimsum Best regards Ole
Bug#1062431: ITP: rust-jpegxl -- crate to work with jpegxl files
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@riseup.net -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-jpegxl Version : 0.0.9 Upstream Contact: Inflation * URL : https://github.com/inflation/jpegxl-rs * License : GPL-3 Programming Lang: Rust Description : crate to work with jpegxl files This crate will be needed to enable jpegxl support for glycin. It covers both the -sys and the jpegxl crate and will be maintained with the Debian Rust team. best, werdahias -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmW7g4UVHHdlcmRhaGlh c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1nbAP/AkNuJwzIIxv6xqd2SKcAdbiPQKL O+zhT1QdEwEjR8VjJfdjP+Vl0nblBbmZz0enEjIt1GeRSUqb44+Ph6Crz86rT54X YNC7lwa+cpIKkQYt52U68pDWx74EUJxDZN6KESs6iOtrggmmN8t+0Ugidxig6FEc 5aRmN6NAvfkTcIaXs1sQ//gNFNRVNAveC0EqY+oW1SUawDMMTT1eBjqg8e/F79DX 3DDcTwsm5sz2PBLb9D155YUsr+5U7ap+ATwYALafN49sVUsIB/W+7isP0xemg6GZ jNtEt4uETWtrip4Rko0ATZ8KOM8AnL9h/vhUXNtGwtx/YXOa6Ko0rEXpksy7G2FA UGCX9cRxEwy7sA0QDx2IEQk0XJV2WUWzkdqramqNzqNG6ri9x9kWfPTcTOUr9OYU iB2t4fva5/XEs0BzqAD9z5hvDScghR1L4TxXdEe9xKIYvVC01na2OSmShGmLEFQn GyW77ZguF+AxNQm+g3iZNKm0S6a+oznjUChgjqItHnBpo+lMkuQyoHEEL9itnX5I aWR6Y3tEDjsw2Jt4DYm9aEXkLvggD+LVZrNvDHFpiBTJM8BWduBbLfVGAUNgO9pu rfplVoZ9Ng4SEaOy3Vahdo9z0pPX1BpnchNb7nSOnFRWdSGQ7FqtaGZ0kZJoAlXC sJp7XHEHsxh74Yj0 =v7W6 -END PGP SIGNATURE-
Bug#1062432: ITP: rust-sourceview5 -- rust binding for gtksourceview
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@riseup.net Control: block 900928 by -1 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: rust-sourceview5 Version : 0.7 Upstream Contact: Bilal Elmoussaoui * URL : https://gitlab.gnome.org/World/Rust/sourceview5-rs/ * License : MIT Programming Lang: Rust Description : rust binding for gtksourceview This ITP covers both the low-level -sys crate and the high level crate. This package will be maintained with the Debian Rust team. best, werdahias -BEGIN PGP SIGNATURE- iQJJBAEBCgAzFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmW7hSYVHHdlcmRhaGlh c0ByaXNldXAubmV0AAoJEBi9EGs7bFR1J7oQAJS1sU3RTVm813Lk51x3fEpTjbq5 cczxcqxZLNiHSlnaQljde8UzaEUoZiSV1P2oFev5lIBOEiD+u7L5rj5eFIBO3YkS N6b6DnXpf0OfecDvZjQcx9tMxGogbH9kfkWy71oGtau/U1GB2SXJaI/zR2GNmcyF l2ls02rRg846Zbv1my78XTBOTYnXfzmvWgCMfiLRpkAbacMG2gejY7rTisY7fnZT J9DKKcA2D63a+wN1uyaeueN2N159PQLA0519sBz+zObA7oWw+vlRy2uFdUJbxs8X uY3MALv/4OGiQb6kA+MpiEsjU952nW7AuPL8fzhwVPpWW2mI/j9btHxpgJcYJW9D 4de9clXfLprxUqflw699AogDj7gvnr2I/tymGQUdcSG0Fj19QxJTdgf02hDbZ3ha DvfosoIPOcJSxCj7gR7gkKopO4hfDuIFqBPyxFK9tcT6UWzZyk0bgSKbHzZWzsLM XsqBIbybrSGcSTkZyp6elcZKlgybSG6Ij2arqScKornI9L2R7Ouahh19ee9hrcM8 3YfDnXmy11sK6mN6oT0nx4NTuaxT3Mh4Bq13Lh/jBf7MyvzDdFEJ/CFVUzKwJMbD q37Jw5bbYo6lX+ngko+vGJd/+ztdHO4ozwQDHRBUTjCPtkpp5UEO3svwDq9CLfNb iewfp/olFc/9pWiJ =bPBB -END PGP SIGNATURE-
Bug#1062436: ITP: bdflib -- Python library and tools for working with BDF font files
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: bdflib Version : 0+git20240201+ds Upstream Authors: Screwtape URL : https://gitlab.com/Screwtapello/bdflib * License : GPL-3-or-later Description : Python library and tools for working with BDF font files This library allows for manipulating fonts directly and comes with command-line utilities for performing various operations on font files.
Bug#1062438: ITP: monobit -- tools for working with monochrome bitmap fonts
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: monobit Version : 0.42.2 Upstream Authors: Rob Hagemans URL : https://github.com/robhagemans/monobit * License : MIT Description : tools for working with monochrome bitmap fonts These tools let you modify bitmap fonts and convert between several formats. . monobit's native format is yaff, a human-friendly, text-based visual format similar to the ones used by Roman Czyborra's hexdraw, Simon Tatham's mkwinfont and John Elliott's psftools. Details are given in the yaff font file format specification.
Bug#1062455: ITP: tiv -- Small command-line image viewer using RGB ANSI colors and Unicode block characters to render image
Package: wnpp Severity: wishlist Owner: "Loren M. Lang" X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: tiv Version : 1.2.1 Upstream Author : Aaron Liu , Stefan Haustein * URL : https://github.com/stefanhaustein/TerminalImageViewer * License : GPL3, ASL Programming Lang: C++ Description : Small command-line viewer using RGB colors and Unicode block characters to render image Small command-line image viewer using 24-bit RGB ANSI colors and Unicode block characters which create a 4x8 pixel cell for each character. With the use of these Unicode block characters, this can provide a higher resolution image for the same screen real estate. It was compared with timg and catimg and can get out finer detail than those tools and make a sharper presentation. The mail_new.png icon seems to have a lot of fine detail with the text on the page. Here is my comparision case: catimg -H 32 /usr/share/icons/mate/256x256/actions/mail_new.png timg -g 32x32 /usr/share/icons/mate/256x256/actions/mail_new.png ./tiv -h 32 -w 32 /usr/share/icons/mate/256x256/actions/mail_new.png I am currently planning on maintaining it myself, but I am open if there is a team that is more appropriate to help with it. The package itself is very lightweight and should not require much maintenance. I will need a sponsor to get this package into Debian. -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Bug#1062463: ITP: xsf-xmpp-xeps -- XMPP Extension Protocols (XEPs)
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Package Name: xsf-xmpp-xeps Version: (git master) Upstream Author: XMPP Standards Foundation License: XSF License (https://github.com/xsf/xeps/blob/master/LICENSE.txt) Programming Lang: XML Homepage: https://github.com/xsf/xeps Description: XMPP Extension Protocols (XEPs) This package contains the specifications produced by the XMPP Standards Foundation (XSF). See http://xmpp.org/ for details. Note, that the core specifications for XMPP are developed at the Internet Engineering Task Force (IETF) and can be found in the (non-free) package doc-rfc-std-proposed.
Re: Transparency into private keys of Debian
Thanks for digging in here, its very important work! I'd be happy to contribute where I can. I'm a DD and a core contributor to F-Droid, where we wrestle with basically the same issues. So we've thought a lot about these kinds of things, but definitely do not have all the answers. Since F-Droid started much later than Debian, we were able to build in some nice protections from the beginning, like requiring HTTPS. We've also made the decision to stick with a single jurisdiction for the singing keys, even though it is not the best one for our needs. We'd of course love to move them to the best jurisdiction but that is actually quite a bit of work, so we have to stay grounded in reality. For me the hard part of all this is how to be transparent as possible without putting a giant target on the heads of the people who control the keys. I think it is clear that publishing private key usage information is safe, like this key signed these things at these times. Publishing all the details about how the key was generated could help those who want to attack it more than those who rely on it. But that kind of information would be good to share internally to the project at the very least. And publishing the jurisdictions could be enough info to deanonymize the key holder, e.g. if it is Germany, then there are many DDs there. If it is Iceland, then govs can easily find who to target. .hc Hi I'm exploring how to defend against an attacker who can create valid signatures for cryptographic private keys (e.g., PGP) that users need to trust when using an operating system such as Debian. A signature like that can be used in a targetted attacks against one victim. For example, apt does not have any protection against this threat scenario, and often unprotected ftp:// or http:// transports are used, which are easy to man-in-the-middle. Even with https:// there is a large number of mirror sites out there that can replace content you get. There is a risk that use of a compromised trusted apt PGP key will not be noticed. Attackers are also in a good position to deny themselves out of their actions if they are careful. Part of my effort is to inventory all trusted private keys that a distribution needs to manage on their own, or depend on that are managed by others, and gain some insight how these keys are handled. Does the Debian project, or any members, publish information on these topics? Has this been discussed before? Some questions that I think would be useful to answer include: 1) List of relevant private keys, held by the organization, its members, or someone else. As far as I can tell from Debian, the list includes the following PGP trust anchors: B8B8 0B5B 623E AB6A D877 5C45 B7C5 D7D6 3509 47F8 05AB 9034 0C0C 5E79 7F44 A8C8 254C F3B5 AEC0 A8F0 4D64 FEC1 19C2 0290 67D6 E791 F8D2 585B 8783 D481 1F89 983E 0081 FDE0 18F3 CC96 73A4 F27B 8DD4 7936 AC53 0D52 0F2F 3269 F5E9 8313 A484 4904 4AAD 5C5D A428 5295 FC7B 1A81 6000 62A9 605C 66F0 0D6C 9793 80D1 5823 B7FD 1561 F9F7 BCDD DC30 D7C2 3CBB ABEE 5E61 B217 265D A980 7A23 C5FF 4DFA B270 CAA9 6DFA 6D33 866E DD8F FA41 C014 3AED DCC9 EFBF 77E1 1517 Compromising any single key on this list leads to trouble. However I don't think this list is complete. What other keys are there? I believe there are keys used to sign some component of the boot phase, compare the 'shim-signed' and 'grub-efi-amd64-signed' packages. What private keys held by Debian are involved here? What keys held by others are involved? What other similar packages exists? 2) For each private key, information about its management and lifecycle. Relevant questions include: a) How was the key generated? By whom? On what hardware? What software? In what environment? What legal jurisdiction apply to people involved? b) How is the key stored and protected during its lifetime? What media is used? Who control the physical storage of the key? How are they stored and transported? What jurisdiction? c) Under what policy is the key used? What should it sign? Who authorize the signing? What hardware and software is used? What jurisdiction? d) For externally held keys, what are the legal terms we use the keys under? What insight into key transparency questions do we have? What of those can we make public? How do they restrict what we are allowed to do? 3) Which less visible private keys are indirectly trusted by users of the distribution? For example, all DD PGP keys are indirectly trusted since they are permitted to make uploads into the archive. Host keys used to authorized access to sensitive systems may also be relevant. I'm primarily thinking SSH private keys to a system that may have online access to a private key signing oracle. Indirectly, questions about authentication protocols and authorization
Bug#1062618: ITP: fonts-topaz-unicode -- Amiga 500 "Topaz" font updated for the 21st century
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fonts-topaz-unicode Version : 1+git20240201+ds Upstream Authors: Screwtape URL : https://gitlab.com/Screwtapello/topaz-unicode * License : ISC Description : Amiga 500 "Topaz" font updated for the 21st century This is therefore a highly nostalgic typeface for people of a certain age and geographical distribution, but it's also a genuinely good font. It's high contrast, it's consistently designed (within the limits of 8x8px), and it's quite compact.
