On some systems, something like this happens:
package_unpack.c:375:11: error: 'buf' may be used uninitialized in this function
This is not actually a bug as logically `buf` is always initialized
in that place, but gcc doesn't like it anyway.
if xbps_repo_open() fails then the repo is removed from array
xbps_repo_remove() but as we've removed the entry from it,
the index won't be valid any more, resulting in skipped entries.
If a entry is removed restart again at the correct index.
Close#127
Found by clang analyzer.
Bug Summary
File: lib/portableproplib/rb.c
Warning: line 363, column 19
Value stored to 'grandpa' during its initialization is never read
It was made many years ago to update the pkgdb format, but
it's innecessary to build it by default because is dead code.
Anyway keep it just in case pkgdb format changes.
Initialize rv to avoid a logic error.
Found by clang-analyzer.
Bug Summary
File: lib/initend.c
Warning: line 101, column 10
The left operand of '<' is a garbage value
Reported by clang-analyzer.
After reading the linux man-pages vfork(2) manpage I came to the
conclusion that it's better to change the behaviour of the
original source (NetBSD) and change this to use fork(2).
Always check if there's a new xbps package version available
while *installing* or *updating* in any form.
This fixes the following scenario:
- xbps-0.53_10 is currently installed
- xbps-0.54_1 is available in repo
- xbps-install --update netbsd-wtf || xbps-install new-pkg || xbps-install --update
As expected any of the following scenarios in last cmd will use *this*
transaction to autoupdate xbps and its reverse dependencies.
Another transaction will be necessary to install or update the other unrelated
packages.
Added a new test case to verify this case and improve the other test
cases with more extensive checks.
xbps_get_pkg_fulldeptree() now returns NULL and sets errno to ENODEV
when there are missing dependencies, rather than assert()ing.
Added another test case to check returned error codes.
Signed-off-by: Juan RP <xtraeme@gmail.com>
As shown in https://github.com/void-linux/xbps/issues/110
/var might be rw, while / might be ro.
Check this via xbps_pkgdb_lock() for both things.
Close#110
Signed-off-by: Juan RP <xtraeme@gmail.com>
The current code was failing because while checking for updates
on its reverse dependencies, up-to-date versions were treated
as an error.
Added a new test case to verify that it works as expected.
Signed-off-by: Juan RP <xtraeme@gmail.com>
Even if the alternatives group is already registered, we need
to create the symlinks from current pkg dictionary (repo).
Signed-off-by: Juan RP <xtraeme@gmail.com>
This fixes the new test case "less_entries_update" contributed
by @duncaen.
If "alternatives" dict from pkgdb differs from the one from repos,
find obsoletes and remove them.
Signed-off-by: Juan RP <xtraeme@gmail.com>
Fix logic as found by @duncaen in #101.
Also set "first" when the entry is removed from the array.
Fixes#102
Signed-off-by: Juan RP <xtraeme@gmail.com>
In the !current branch, "first" wasn't initialized so it displayed garbage:
Removing `pinentry-tty-1.1.0_5' ...
Removing 'pinentry' alternatives group symlink: pinentry
pinentry-tty-1.1.0_5: unregistered 'pinentry' alternatives group
Switched 'pinentry' alternatives group to 'p
o@�'
Creating 'pinentry' alternatives group symlink: pinentry -> /usr/bin/pinentry-tty
Removed file `/usr/bin/pinentry-tty'
Removed `pinentry-tty-1.1.0_5' successfully.
With my fix:
Removing `pinentry-tty-1.1.0_5' ...
Removing 'pinentry' alternatives group symlink: pinentry
pinentry-tty-1.1.0_5: unregistered 'pinentry' alternatives group
Switched 'pinentry' alternatives group to 'pinentry'
Creating 'pinentry' alternatives group symlink: pinentry -> /usr/bin/pinentry-tty
Removed file `/usr/bin/pinentry-tty'
Removed `pinentry-tty-1.1.0_5' successfully.
Signed-off-by: Juan RP <xtraeme@gmail.com>
This fixes the cases where a pkg installation or update
could break its revdeps due to not satisfying dependencies.
When performing an install or update, xbps now always checks if
there are updates for its revdeps and get added to the transaction.
See the two new test cases for more information.
Splitting the socks5 request is causing issues when running against Tor.
It causes Tor to fail with an address unknown error. Assembling the
request and sending it in its entirety solves the issue.
An strace of torsocks, that functions correctly when used with xbps, shows
that the request is being sent all at once:
recvfrom(3, "\5\0", 2, 0, NULL, NULL)
sendto(3, "\5\1\0\3>lysator7eknrfl47rlyxvgeamrv7ucefgrrlhk7rouv3sna25asetwid.onion\0P", 69, 0, NULL, 0)
recvfrom(3, "\5\0\0\1\0\0\0\0\0\0", 10, 0, NULL, NULL)
Closes: #54 [via git-merge-pr]
The previous idea was to use virtual packages in the users configuration
to satisfy dependencies by mapping them to existing installed packages.
Using virtual packages for it doesn't work as expected and trying to make
it work would break other functionalities of virtual packages, like the
version satisfaction checks for `provides` and the ability to replace
virtual packages with real packages. The virtual package functionality
should be used exclusively for virtual packages.
This allows users to specify packages packages that should be ignored.
Ignored packages in dependencies are always satisfied without installing
the package, while updating or installing a package that depends on an
ignored package.
This does NOT ignore the shlib checks, ignoring a package that provides
required shared libraries will abort the transaction as if there was no
package that provides the required shared library.
Connect to the addresses from `getaddrinfo(3)`,
alternating between address family,
starting with ipv6 and wait `fetchConnDelay`
between each connection attempt.
If a connection is established within the attempts,
use this connection and close all others.
If `connect(3)` returns `ENETUNREACH`, don't attempt more
connections with the failing address family.
If there are no more addresses to attempt,
wait for `fetchConnTimeout` and return the first established
connection.
If no connection was established within the timeouts,
close all sockets and return -1 and set errno to
`ETIMEDOUT`.
faster: use a hash table with pkg names on the transaction dict,
the process of collecting and sorting is now 50x faster or
even more (kde5).
bugs: this now detects cyclic deps and returns with an appropropiate
return value: ELOOP and ENOENT in xbps-query(1) --fulldeptree.
Ping me if you need more details :-)
Close https://github.com/void-linux/xbps/issues/16
Close https://github.com/void-linux/xbps/issues/5
The order of entries in files.plist is inconsistent
between different releases of xbps. Hence they must be
ordered before removal to, so sub directories are removed
before their parents.
Before this patch xbps had a constant slice count for every thread.
This resulted in unbalanced thread usage if the workload was
homogenous over the slices.
This patch replaces the naive slice count approach by spinlock based
reservation.
This is a trickier situation.
The original message:
```
initend.c:423:10: error: ‘%s’ directive output may be truncated writing 15 bytes into a region of size between 1 and 512 [-Werror=format-truncation=]
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:422:3: note: ‘snprintf’ output between 16 and 527 bytes into a destination of size 512
snprintf(xhp->confdir, sizeof(xhp->confdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_SYSCONF_PATH);
~~~~~~~~~~~~~~~~~~
initend.c:429:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:428:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->confdir, sizeof(xhp->confdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initend.c:434:9: error: ‘%s’ directive output may be truncated writing 17 bytes into a region of size between 1 and 512 [-Werror=format-truncation=]
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:433:2: note: ‘snprintf’ output between 18 and 529 bytes into a destination of size 512
snprintf(sysconfdir, sizeof(sysconfdir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_SYSDEFCONF_PATH);
~~~~~~~~~~~~~~~~~~~~~
initend.c:455:11: error: ‘%s’ directive output may be truncated writing 14 bytes into a region of size between 0 and 511 [-Werror=format-truncation=]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:454:3: note: ‘snprintf’ output between 16 and 527 bytes into a destination of size 512
snprintf(xhp->cachedir, sizeof(xhp->cachedir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_CACHE_PATH);
~~~~~~~~~~~~~~~~
initend.c:461:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:460:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->cachedir, sizeof(xhp->cachedir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initend.c:467:11: error: ‘%s’ directive output may be truncated writing 12 bytes into a region of size between 0 and 511 [-Werror=format-truncation=]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
^~
initend.c:466:3: note: ‘snprintf’ output between 14 and 525 bytes into a destination of size 512
snprintf(xhp->metadir, sizeof(xhp->metadir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
XBPS_META_PATH);
~~~~~~~~~~~~~~~
initend.c:473:7: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation ]
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
^~~~~~~
initend.c:472:3: note: ‘snprintf’ output 2 or more bytes (assuming 513) into a destination of size 512
snprintf(xhp->metadir, sizeof(xhp->metadir),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%s/%s", strcmp(xhp->rootdir, "/") ? xhp->rootdir : "", buf);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
It's basically warning about dangerous operations on strings. And as
far as I could tell, is a valid warning and not a false alarm!
This fix makes the concept of `XBPS_MAXPATH` lose a little bit of sense
as now it doesn't necessarily represent the max size of the paths used
by xbps, but instead the max allowed size of the path configured.
I think this change is ok, but I wasn't able to find any reference to
why it was chosen to be 512. POSIX mandates at least 256, so I'm not
breaking anything that wasn't broken already, and Linux seems to have
a maximum size of 4096, which is pretty safe.
Therefore, this changes should be harmless. I think.
When trying to compile the file ftp.c, I get errors related with
warnings that were marked to be reported as error.
This was the original message:
```
fetch/ftp.c:444:8: error: this statement may fall through [-Werror=implicit-fallthrough=]
type = 'D';
~~~~~^~~~~
fetch/ftp.c:445:2: note: here
case 'D':
^~~~
fetch/ftp.c: In function ‘ftp_request’:
fetch/ftp.c:342:3: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
for (i = 0; i <= len && i <= end - dst; ++i)
^~~
fetch/ftp.c:342:24: error: missed loop optimization, the loop counter may overflow [-Werror=unsafe-loop-optimizations]
for (i = 0; i <= len && i <= end - dst; ++i)
~~~~~~~~~^~~~~~~~~~~~~~~~~
```
$ARCH-repodata is currently not protected by a signature. While most of
the package metadata is also embedded into the .xbps files, which are
protected by a signature, xbps-install ignores it
(1670ff000d/lib/package_unpack.c (L123))
and relies entirely on $ARCH-repodata.
This enables anyone who is able to modify the $ARCH-repodata to
substitute packages. This patch adds a check that verifies the signed
pkgver matches the one in the repodata, so at least downgrades posing as
updates are detected.
This is an incomplete fix as the whole transaction is still set up with
the unsigned repodata and other issues surely exist. The real fix is
signing $ARCH-repodata.
Calling EVP_cleanup here undoes initialization already done in
lib/fetch/common.c ssl_init() causing subsequent attempts to call
SSL_CTX_new() to fail. Which ultimately is the root cause for #170.
Fixes#170
xbps_find_virtualpkg_in_conf() needs to look at the vpkgs set up in
configuration files, not from those set by pkgdb.
As a result of this the two test cases that were failing yesterday are now
fixed.
When adding packages to the index, xbps-rindex will check if the
consistency of shlibs is broken by a package. If so, rindex will create
a stage file and commit the packages there. Once the consistency is restored,
rindex -a will commit the stage area back to the public repo and delete the
stage file.
When adding packages to the index, xbps-rindex will check if the
consistency of shlibs is broken by a package. If so, rindex will create
a stage repository and commit the packages there. Once the consistency
is restored, rindex -a will commit the stage area back to the public
repo and delete the stage file.
This commit adds relative link support to lib/package_alternatives.c.
Instead of creating absolute links, xbps will create relative links
to the target. This allows to follow links on systems even if the
aren't mounted on /.
The default CA file set by FreeBSD is only available when using the
LibreSSL provided CA file, and we've decided to use the CA path
by default.
Discussed with @dominikh.
While xbps_fetch_file() creates the .part file and for whatever reason
it did not finish properly to rename the file, it could request the server
to restart the download with offset set to file size, resulting in HTTP 416
return code.
Handle this case by checking if the server returns 416 and then checking
if the returned file size matches the requested offset and just rename
the file.
Thanks to @beefcurtains for the test case.
Those are a wrapper around xbps_{array,dictionary}_internalize_from_zfile()
that prints a debugging msg when the plist file cannot be internalized.
Update xbps to use these wrappers.
We use a simple file lock that is created with O_CREAT|O_EXCL.
This should fix the concurrency issues with multiple processes
running xbps-rindex -a/-c on the same repository/arch combo.
At the time we've been searching for the pkg in a repo, no repos
were registered resulting in EINVAL. While here, if there's no
declared repos return ENOENT instead.
