| Age | Commit message (Collapse) | Author |
|---|
|
This is possible now with the API break. Cleaner code, woohoo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 51ac850da87c606a45214ba03711c4a3c5c1c780.
|
|
apt Debian release 1.8.0~rc4
|
|
|
|
These will run in our frontends currently, and can show
messages. For the sake of keeping the implementation
complexity low, a non-success variant of Post-Invoke
is not provided.
LP: #1815761
|
|
This is run after an update has been run and only if status on the
new cache has been shown, allowing scripts to display their own
status messages.
LP: #1815760
|
|
apt Debian release 1.8.0~rc3
|
|
|
|
Seems we missed those before.
|
|
|
|
Closes: #921941
Reviewed-By: Debian L10n Dutch <debian-l10n-dutch@lists.debian.org>
|
|
Closes: #921934
Reviewed-By: Debian L10n Dutch <debian-l10n-dutch@lists.debian.org>
|
|
|
|
Closes: #921830
Thanks: Vladimir Zhbanov <vzhbanov@gmail.com>
|
|
This was removed in dh 12, and dh_missing is run by default which
detects missing files.
|
|
Switch from debian/compat to the new Build-Depends syntax - that's
way nicer.
|
|
|
|
Last entry included an item that was not in the release,
and the one before that was signed with the wrong email
address.
|
|
This is a special case here, a best effort write, so there's no
point in having warnings about it for every method.
|
|
Not a lot of fancy new stuff there, but some good stuff. Would
like to use C++17, but might not be stable yet.
|
|
|
|
Mistakingly used #define instead of #cmakedefine
|
|
|
|
This slightly improves performance, as std::to_string() (as in gcc's
libstdc++) avoids a heap allocation. This is surprisingly performance
critical code, so we might want to improve things further in 1.9
by manually calculating the string - that would also get rid of issues
with locales changing string formatting, if any.
|
|
This fixes the build on kfreebsd-amd64, and due to the detection
of sse4.2, should also enable the sse4.2 on i386.
|
|
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.
|
|
A pin of -32768 overrides any other, disables repo
See merge request apt-team/apt!40
|
|
This new field allows a repository to declare that access to
packages requires authorization. The current implementation will
set the pin to -32768 if no authorization has been provided in
the auth.conf(.d) files.
This implementation is suboptimal in two aspects:
(1) A repository should behave more like NotSource repositories
(2) We only have the host name for the repository, we cannot use
paths yet.
- We can fix those after an ABI break.
The code also adds a check to acquire-item.cc to not use the
specified repository as a download source, mimicking NotSource.
|
|
This allows disabling a repository by pinning it to 'never',
which is internally translated to a value of -32768 (or whatever
the minimum of short is).
This overrides any other pin for that repository. It can be used
to make sure certain sources are never used; for example, in
unattended-upgrades.
To prevent semantic changes to existing files, we substitute
min + 1 for every pin-priority: <min>. This is a temporary
solution, as we are waiting for an ABI break.
To add pins with that value, the special Pin-Priority
"never" may be used for now. It's unclear if that will
persist, or if the interface will change eventually.
|
|
Fail if InRelease or Release.gpg contain unsigned lines
See merge request apt-team/apt!45
|
|
Closes: #921008
Reviewed-By: Debian L10n French <debian-l10n-french@lists.debian.org>
|
|
Closes: #921011
|
|
Implementing a parser with recursion isn't the best idea, but in
practice we should get away with it for the time being to avoid
needless codechurn.
Closes: #920317 #921037
|
|
It is dropped in the merged code, but the extraction of the clearsigned
message code was the only one who had it previously, so the short-desc
explains the change from a before-after merge of the branch PoV.
It would make sense to enable it, but as we aren't in a time critical
paths here we can delay this for after buster to avoid problems.
References: 73e3459689c05cd62f15c29d2faddb0fc215ef5e
Suggested-By: Julian Andres Klode
|
|
Suggested-By: Julian Andres Klode
Gbp-Dch: Ignore
|
|
Verify data being sent by methods in SendMessage()
See merge request apt-team/apt!48
|
|
These methods are not supposed to be used anymore, they are
not actively maintained and may hence contain odd bugs.
Fixes !49
|
|
As a follow-up for CVE-2019-3462, add checks similar to those
for redirect to the central SendMessage() function. The checks
are a bit more relaxed for values - they may include newlines
and unicode characters (newlines get rewritten, so are safe).
For keys and the message header, the checks are far more strict:
They may only contain alphanumerical characters, the hyphen-minus,
and the horizontal space.
In case the method tries to send anything else, we construct a
legal 400 URI Failed response, and send that. We specifically do
not include the item URI, in case it has been compromised (that
would cause infinite recursion).
|
|
No effective change in behaviour, just simplifying and reusing code.
Suggested-By: Julian Andres Klode
Gbp-Dch: Ignore
|
|
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
|
|
private-json-hooks.cc: deal with EPIPE
See merge request apt-team/apt!47
|
|
While running our CI we noticed that sometimes we see an error
from the new json hooks code. The error message is:
```
E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Broken pipe
```
when purging the snapd package which provides the hook. This indicates
that we should probably also consider EPIPE not an error (just like
we do for ECONNRESET). This PR does exactly this.
|
|
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.
|
|
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
|
