Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=2.2.1 2021-02-04T10:00:00Z 2021-02-04T10:00:00Z David Kalnischkies david@kalnischkies.de 2020-06-28T18:52:09Z urn:sha1:96dc40b19623621a9cc2c5541fb3adbbceb553b1 varg API is a nightmare as the symbols seems different on ever other arch, but more importantly SendMessage does a few checks on the content of the message and it is all outputted via C++ iostreams and not mixed in FILE* which is handy for overriding the streams. 2020-05-06T10:33:39Z Julian Andres Klode julian.klode@canonical.com 2020-05-06T10:33:39Z urn:sha1:ee284d5917d09649b68ff1632d44e892f290c52f People are still using apt-key add and friends, despite that not being guaranteed to work. Let's tell them to stop doing so. We might still want a list command at a future point, but this needs deciding, and a blanket ban atm seems like a sensible step until we figured that out. 2019-03-03T20:52:40Z David Kalnischkies david@kalnischkies.de 2019-03-03T18:41:42Z urn:sha1:3e3638dc9389591cfd30baa6c41d85c31127402a Verifying the content of Release.gpg made us fail on binary signatures which were never officially supported (apt-secure manpage only documents only the generation of ASCII armored), but silently accepted by gpgv as we passed it on unchecked before. The binary format is complex and is itself split into old and new formats so adding support for this would not only add lots of code but also a good opportunity for bugs and dubious benefit. Reporting this issue explicitly should help repository creators figure out the problem faster than the default NODATA message hinting at captive portals. Given that the binary format has no file magic or any other clear and simple indication that this is a detached signature we guess based on the first two bits only – and by that only supporting the "old" binary format which seems to be the only one generated by gnupg in this case. References: e2965b0b6bdd68ffcad0e06d11755412a7e16e50 Closes: #921685 2019-02-04T13:43:16Z Julian Andres Klode julian.klode@canonical.com 2019-02-04T13:43:16Z urn:sha1:cde5ee8fe527d3d672775909d27110d11c393774 This is safe here, as the code ensures that the file is flushed before it is being used. The next series should probably make GetTempFile() buffer writes by default. 2019-02-01T13:02:08Z David Kalnischkies david@kalnischkies.de 2019-02-01T13:02:08Z urn:sha1:fd438818d2518901396d6835f845b0b90c3a82fa Suggested-By: Julian Andres Klode Gbp-Dch: Ignore 2019-01-29T15:08:39Z David Kalnischkies david@kalnischkies.de 2019-01-29T14:34:56Z urn:sha1:cd852177246a5ea52ae3fda12b8d991a1ad8d351 No effective change in behaviour, just simplifying and reusing code. Suggested-By: Julian Andres Klode Gbp-Dch: Ignore 2019-01-29T12:57:19Z David Kalnischkies david@kalnischkies.de 2019-01-29T12:57:19Z urn:sha1:7107b3a056211daf7cd00b130f42168d6aa1e1b6 No change in the logic itself, just dropping "== true", replacing "== false" with not and moving lines around to make branches more obvious. Suggested-By: Julian Andres Klode Gbp-Dch: Ignore 2019-01-28T19:45:02Z David Kalnischkies david@kalnischkies.de 2019-01-28T19:45:02Z urn:sha1:9b840b59cc80a072e14b8adc9d76669a7a50ab87 We support dash-encoding even if we don't really work with files who would need it as implementations are free to encode every line, but otherwise a line starting with a dash must either be a header we parse explicitly or the file is refused. This is against the RFC which says clients should warn on such files, but given that we aren't expecting any files with dash-started lines to begin with this looks a lot like a we should not continue to touch the file as it smells like an attempt to confuse different parsers by "hiding" headers in-between others. The other slightly more reasonable explanation would be an armor header key starting with a dash, but no existing key does that and it seems unlikely that this could ever happen. Also, it is recommended that clients warn about unknown keys, so new appearance is limited. 2019-01-28T17:41:22Z David Kalnischkies david@kalnischkies.de 2019-01-28T17:33:31Z urn:sha1:93c9a49c1fd378cd0a3b472d68afb3378da145b8 This is C++, so we can use a bit more abstraction to let the code look a tiny bit nicer hopefully improving readability a bit. Gbp-Dch: Ignore 2019-01-28T17:17:00Z David Kalnischkies david@kalnischkies.de 2019-01-28T17:17:00Z urn:sha1:c8350b2b0b77bacf6a1b42eade20002546baac3a RFC 4880 section 7.1 "Dash-Escaped Text" at the end defines that only space and tab are allowed, so we should remove only these even if due to use complaining (or now failing) you can't really make use of it. Note that strrstrip was removing '\r\n\t ', not other whitespaces like \v or \f and another big reason to do it explicitly here now is to avoid that a future change adding those could have unintended consequences.