This gives us more granularity than the former Never/Optional/Always
trifecta. The frontend still uses these values temporarily but that will
be changed in a future patch.
* Use 'siglevel' consistenly in method names, 'level' as variable name
* The level becomes an enum bitmask value for flexibility
* Signature check methods now return a array of status codes rather than
a simple integer success/failure value. This allows callers to
determine whether things such as an unknown signature are valid.
* Specific signature error codes mostly disappear in favor of the above
returned status code; pm_errno is now set only to PKG_INVALID_SIG or
DB_INVALID_SIG as appropriate.
Signed-off-by: Dan McGee <dan@archlinux.org>
The following function renames take place for the same reasoning as
the previous commit:
_alpm_grp_new -> _alpm_group_new
_alpm_grp_free -> _alpm_group_free
_alpm_db_free_grpcache -> _alpm_db_free_groupcache
_alpm_db_get_grpfromcache -> _alpm_db_get_groupfromcache
Signed-off-by: Allan McRae <allan@archlinux.org>
Using grp instead of group is a small saving at the cost of clarity.
Rename the following functions:
alpm_option_get_ignoregrps -> alpm_option_get_ignoregroups
alpm_option_add_ignoregrp -> alpm_option_add_ignoregroup
alpm_option_set_ignoregrps -> alpm_option_set_ignoregroups
alpm_option_remove_ignoregrp -> alpm_option_remove_ignoregroup
alpm_db_readgrp -> alpm_db_readgroup
alpm_db_get_grpcache -> alpm_db_get_groupcache
alpm_find_grp_pkgs -> alpm_find_group_pkgs
Signed-off-by: Allan McRae <allan@archlinux.org>
Start by converting all of our flags to a 'status' bitmask (pkgcache
status, grpcache status). Add a new 'valid' flag as well. This will let
us keep track if the database itself has been marked valid in whatever
fashion.
For local databases at the moment we ensure there are no depends files;
for sync databases we ensure the PGP signature is valid if
required/requested. The loading of the pkgcache is prohibited if the
database is invalid.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is another step toward doing both local database validation
(ensuring we don't have depends files) and sync database validation (via
signatures if present) when the database is registered.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is the ideal place to do it as all clients should be checking the
return value and ensuring there are no errors. This is similar to
pkg_load().
We also add an additional step of validation after we download a new
database; a subsequent '-y' operation can potentially invalidate the
original check at registration time.
Note that this implementation is still a bit naive; if a signature is
invalid it is currently impossible to refresh and re-download the file
without manually deleting it first. Similarly, if one downloads a
database and the check fails, the database object is still there and can
be used. These shortcomings will be addressed in a future commit.
Signed-off-by: Dan McGee <dan@archlinux.org>
We didn't do due diligence before and ensure prior pm_errno values
weren't influencing what happened in further ALPM calls. I observed one
case of early setup code setting pm_errno to PM_ERR_WRONG_ARGS and that
flag persisting the entire time we were calling library code.
Add a new CHECK_HANDLE() macro that does two things: 1) ensures the
handle variable passed to it is non-NULL and 2) clears any existing
pm_errno flag set on the handle. This macro can replace many places we
used the ASSERT(handle != NULL, ...) pattern before.
Several other other places only need a simple 'set to zero' of the
pm_errno field.
Signed-off-by: Dan McGee <dan@archlinux.org>
This method is old, it doesn't adequately check for a NULL server list,
and can easily be done using better API method we provide these days.
All former users of this method can get similar results by calling
alpm_db_get_servers() and using the data from the returned server list.
Signed-off-by: Dan McGee <dan@archlinux.org>
Note that is a bit different than the normal _alpm_db_path() method; the
caller is expected to free the result.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is the last user of our global handle object. Once again the diff
is large but the functional changes are not.
Signed-off-by: Dan McGee <dan@archlinux.org>
The siglevel field of a newly created pmdb_t struct is now
initialized when it is created in _alpm_db_new().
Signed-off-by: Kerrick Staley <mail@kerrickstaley.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
A few of these snuck in as of late, some from the table display patches
that were using the previous format before we changed it after the 3.5.X
major release.
Noticed-by: Kerrick Staley <mail@kerrickstaley.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
This requires a lot of line changes, but not many functional changes as
more often than not our handle variable is already available in some
fashion.
Signed-off-by: Dan McGee <dan@archlinux.org>
These new method signatures return and take handle objects to operate on
so we can move away from the idea of one global handle in the API. There
is also another important change and that deals with the setting of root
and dbpaths. These are now done at initialization time instead of using
setter methods. This allows the library to operate more safely knowing
that paths won't change underneath it.
Signed-off-by: Dan McGee <dan@archlinux.org>
This will make the patching process less invasive as we start to remove
this variable from all source files.
Signed-off-by: Dan McGee <dan@archlinux.org>
These are simple accessor functions for a struct; the handle never even
comes into play when calling these functions.
Signed-off-by: Dan McGee <dan@archlinux.org>
The usefulness of this is rather limited due to it not being compiled
into production builds. When you do choose to see the output, it is
often overwhelming and not helpful. The best bet is to use a debugger
and/or well-placed fprintf() statements.
Signed-off-by: Dan McGee <dan@archlinux.org>
Currently we have one call that has all sorts of crazy behavior and doesn't
make a whole lot of sense. Go from one method to the normal four methods we
have for all of our other lists we use in the library to make it a lot
easier for a frontend to manipulate server lists.
Signed-off-by: Dan McGee <dan@archlinux.org>
Rather than go through all the hassle of doing this ourselves, just let
GPGME handle the work by passing it a file handle.
Signed-off-by: Dan McGee <dan@archlinux.org>
This does touch a lot of things, and hopefully doesn't break things on
other platforms, but allows us to also clean up a bunch of crud that no
longer needs to be there.
Signed-off-by: Dan McGee <dan@archlinux.org>
This is the standard, and we have had a few of these introduced lately
that should not be here.
Done with:
find -name '*.c' | xargs sed -i -e 's#if (#if(#g'
find -name '*.c' | xargs sed -i -e 's#while (#while(#g'
Signed-off-by: Dan McGee <dan@archlinux.org>
pacman 3.5.0 removed alpm_db_register_local, so calling
alpm_db_unregister_all leaves the front end in a position where there's
no local db, and no way to re-register it.
Signed-off-by: Dave Reisner <d@falconindy.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
Add a pmpgpsig_t struct to the database entry struct and functions for
the lazy loading of database signatures. Add a function for checking
database signatures, reusing (and generalizing) the code currently used
for checking package signatures.
TODO: The code for reading in signature files from the filesystem is
duplicated for local packages and database and needs refactoring.
Signed-off-by: Allan McRae <allan@archlinux.org>
Once we do this, add support for VerifySig to pactest. We just check if
the repo name contains Always, Never or Optional to determine the value
of VerifySig. The default is Never. pacman uses Always by default but
this is not suitable for pactest.
Original-work-by: shankar <jatheendra@gmail.com>
Signed-off-by: Xavier Chantry <shiningxc@gmail.com>
Signed-off-by: Dan McGee <dan@archlinux.org>
