| Age | Commit message (Collapse) | Author |
|---|
|
Queues for processes like rred are not created by hostname but we
spawn at most CPU*2 queues to place items in. The problem is that we
then proceeded to limit it to at most 10 queues (via QueueHost::Limit)
again at the end of the method so that all items (after the first 10
queues are busy) are forcibly placed into a generic catch-all instance
which is bad because we don't keep all CPUs we have available busy and
worse we end up sheduling the most work to a single one while random
distribution was intended.
|
|
warning: but ‘pkgTagFilePrivate::FileChunk::FileChunk(bool, size_t)’
does not throw; perhaps it should be declared ‘noexcept’ [-Wnoexcept]
Reported-By: gcc-9
Gbp-Dch: Ignore
|
|
Add PkgConfig on the apt-pkg and apt-inst libraries
See merge request apt-team/apt!20
|
|
|
|
Closes: #439121
|
|
apt Debian release 1.8.0
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Please use the standard C++ variants instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This keeps the members in the class, but makes them private. We
want to migrate to libgcrypt eventually, since we already use
libgcrypt through gpgv anyway.
|
|
|
|
|
|
|
|
Clean up the code, make it neat, lalala
|
|
|
|
|
|
|
|
This is possible now with the API break. Cleaner code, woohoo.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
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).
|
