Negative trust for conflict resolution in software
management
Giuseppe Primiero
Department of Philosophy, University of Milan
Jaap Boender
Department of Computer Science, Middlesex University London
November 7, 2018
Abstract
Software management systems need to preserve integrity by the han-
dling, approval, tracking and execution of changes on the packages of the
current installation profile. This is a problematic task, which needs to be
accounted for both in terms of installation of new packages and removal
of conflicting ones. While existing approaches are able to identify depen-
dency satisfaction and conflicts, a broader and efficient approach can be
formalised in terms of trust. Positive instances of trust are required by
the identification of safely installable packages. Negative trust, a much
less explored concept, can be useful to analyse the complementary issue of
packages’ removal both in case of conflicts and of security issues. In this
paper we develop a logic of negative trust with two aims: identifying pack-
ages that are undesirable in view of the current installation profile; and
currently installed packages that become inconsistent with a new intended
installation. The logic provides distinct procedures for the identification
of either case. We illustrate properties of the calculus, provide a simple
working example and offer a translation of the protocol to the Coq proof
assistant for verification of its formal correctness.
1 Introduction
Software management configuration is among the most pervasive problems in
modern personal computing. The maintenance of a consistent and functioning
software system is complicated by the ability of modern systems to accommodate
multiple users, by the need of releases to preserve package compatibility across
versions and customizations, and the essential coherence required by distributed
systems, especially in the context of web and cloud services. One of the specific
aspects involved by these issues is software change management: the handling,
approval, tracking and execution of changes on the packages of the current
installation profile, with the crucial requirement that integrity of the system
1
be preserved. In most cases, users manage their installation profile through a
software package system which satisfies integrity through an underlying logical
notion of validity.
Definition 1 (Valid Installation profile). An installation profile is valid if and
only if all dependencies for the installed packages are met and all conflicts are
avoided.
The aim of software management is to preserve validity, which can be af-
fected by installation of new packages. Let us illustrate this issue with a simple
example. The server-side software underlying the package management system
in the free operating system Debian and its numerous derivatives is called dpkg;
the user typically accesses it through the apt tool. Binary packages are capable
of declaring their dependencies and conflicts and this allows the system to main-
tain profile validity.
1
When a conflict is declared between two packages, dpkg
forbids them to be unpacked on the system at the same time. So a package φ
conflicts with package ψ when φ will not operate if ψ is installed on the system.
If one of the two is already installed in the profile, then it must be removed
before the other one can be unpacked. If the package intended for installation
is marked as replacing another one on the system, or the one on the system is
marked as deselected, then dpkg will remove the package which is causing the
conflict. If both packages are marked Essential, it will halt the installation of
the new package with an error. This makes sure that essential packages are not
substituted by non-essential ones. This also illustrates that packages and their
dependencies come with a priority relation. Note also that sharing functionali-
ties with another package is not a sufficient reason to declare conflicts with that
package.
1.1 An example
Let us consider the dependencies list for the Tor package from Figure 1: this
list presents an underlying conflict with libsl0.9.8 which, as shown in Figure
2, is an outdated package version which is no longer available in the reposi-
tory: this conflict could be resolved by manual installation or just by admitting
the required higher version libsl1.0.0 of the library involved by the conflict.
Moreover, the Tor Bundle depends on the package libc6, which is the C Gnu
library required by any program in that language.
Consider now that a user under this same installation profile attempts an
installation of the package triggering the dependencies listed in Figure 3: this
package induces the upgrade and associated error with libc6 illustrated in
Figure 4.
2
The software package hedgewars requires an upgrade on libc6;
this would require overwriting it with its replacement; but the library cannot
be (temporarily) removed, as it is required by Tor. In other words, libc6
has unresolvable dependencies while, at the same time, removing it becomes
1
https://www.debian.org/doc/debian-policy/ch-relationships.html\#s-conflicts
for details.
2
This error is reported at https://ubuntuforums.org/showthread.php?t=1091866.
2
gprimiero@xps:˜ apt−cache depends tor
tor
Depends: libc6
Depends: libevent−2.0−5
Depends: libseccomp2
Depends: libssl1 .0.0
Depends: libsystemd0
Depends: zlib1g
Depends: adduser
Depends: init−system−helpers
Depends: lsb−base
Conflicts : <libssl0.9.8>
Recommends: logrotate
Recommends: tor−geoipdb
Recommends: torsocks
Suggests: mixmaster
Suggests: torbrowser−launcher
Suggests: socat
Suggests: tor−arm
Suggests: apparmor−utils
Suggests: obfsproxy
Suggests: obfs4proxy
Figure 1: List of dependencies for Tor Package.
gprimiero@xps:˜ sudo apt−get install libssl0 .9.8
Error:
Reading package lists... Done
Building dependency tree
Reading state information ... Done
Package libssl0 .9.8 is not available , but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package ’ libssl0 .9.8 ’ has no installation candidate
Figure 2: Conflict message for obsolete package libssl0.9.8.
hard due to the number of other packages that depend on it, including the Tor
Bundle.
This example illustrates that an optimal conflict resolution strategy would
make the user not only aware that libssl0.9.8 is not safe to be installed in view
of the direct conflict with Tor (as indeed apt does); but also that hedgewars is
non-safe in view of the current installation, because installing it would require
Tor to be removed, due to its dependency in view of the given version of libc6.
Determining these consistency relations between packages in a given instal-
lation profile is essential for the system’s stability, but also to prevent the pos-
sibility of security threats in critical systems: if the system at hand is meant
to control infrastructure rather than allow to play games, unsafety means a lot
more.
1.2 The Uninstall Problems
The ability to determine which and how many software packages would need
to be removed by the installation of a new one, is therefore an essential aspect
3
gprimiero@xps:˜ sudo apt−get install hedgewars
Upgraded the following packages:
fp−compiler (2.2.0−dfsg1−9ubuntu1) to 2.2.2−8
fp−units−base (2.2.0−dfsg1−9ubuntu1) to 2.2.2−8
fp−units−misc (2.2.0−dfsg1−9ubuntu1) to 2.2.2−8
fp−units−rtl (2.2.0−dfsg1−9ubuntu1) to 2.2.2−8
libc6 (2.8˜20080505−0ubuntu9) to 2.9−4
libc6−amd64 (2.8˜20080505−0ubuntu9) to 2.9−4
libc6−dev (2.8˜20080505−0ubuntu9) to 2.9−4
libc6−dev−amd64 (2.8˜20080505−0ubuntu9) to 2.9−4
libc6−i686 (2.8˜20080505−0ubuntu9) to 2.9−4
Figure 3: Requirement for installation of hedgewars package
gprimiero@xps:˜
Unpacking replacement libc6 ...
dpkg: error processing /var/cache/apt/archives/libc6 2.9−4 i386.deb
(−−unpack):
trying to overwrite ‘/usr/share/man/man1/localedef.1.gz’,
which is also in package belocs−locales−bin
dpkg−deb: subprocess paste killed by signal (Broken pipe)
Processing triggers for man−db ...
Errors were encountered while processing:
/var/cache/apt/archives/libc6 2.9−4 i386.deb
Figure 4: Conflict message for required libc6 library.
of software management. This not only to provide confidence on the safety of
the system, but also to allow the user to asses the risks and changes required.
The problem of maintaining profile consistency and system integrity in view of
uninstall processes has already been addressed in the literature. In [50], the
problem is presented in the following terms:
Definition 2. (Uninstall Problem). Given a new package φ to install, de-
termine the minimal number of packages (possibly none) that must be removed
from the system in order to make φ installable.
This means identifying and removing all packages ψ
1
, . . . , ψ
n
currently in-
stalled that are in conflict with the intended installation of φ and all of its
dependencies ξ
1
, . . . , ξ
n
. This version of the problem can be complemented by
that of identifying packages that depend on an undesired one.
Definition 3. (Uninstall Problem (Alternative Version)). Given a new
package φ whose installation needs to be prevented, determine for which other
packages depending on φ installation has to be prevented.
This means identifying all packages ξ
1
, . . . , ξ
n
depending on the package φ
that is in conflict with some of the currently installed packages ψ
1
, . . . , ψ
n
and
for which installation needs to be prevented.
The relations between client and software repository illustrated by these
problems can be reformulated in terms of trust. In particular, in the example
from the previous subsection, we are considering instances of negative trust: if
trust is granted to a package which preserve profile validity, then trust should
be denied to any package that threatens such consistency (and completeness).
4
Whatever the nature of the interested property breach, we can express this func-
tionally as a trust denial operation. In our example, libssl0.9.8 is strictly
untrustworthy under the current installation; and, provided the intended instal-
lation of hedgewars, the package Tor looses its trustworthiness status, provided
it depends on libc6 which would need to be removed. Obviously, this relation
is instantiated also in a different form: hedgewars should be labelled untrust-
worthy, and more so than libssl0.9.8, as the damage it induces to system’s
stability is so much more vast.
This illustrates how an account of the effects of conflicts is essential, as well
as a description of how procedurally different operations can be performed to
resolve the same conflict. Negative instances of trust have a complex, and so
far little studied, meaning. One way to clarify it is by clearly distinguishing
between two of its forms: here and in the following the term untrust is used as
neutral for ‘negative trust’ with respect to its derivatives mistrust and distrust,
where the former expresses trust removal, the latter trust denial. These two
types of operations can be used to formalize different approaches to conflict
prevention and conflict resolution. On this basis, we adapt here the Uninstall
Problems from Definitions 2 and 3 to the two semantics of untrust:
Definition 4. (Mistrusted Uninstall Problem) Given a package φ to be
installed but conflicting with the current profile, determine which packages have
to be mistrusted in order for φ to become installable.
As in the approach from [50], we are interested here in determining the
minimal set of packages inconsistent with φ that eventually have to be removed
from the installation profile.
Definition 5. (Distrusted Uninstall Problem) Given a distrusted package
φ, determine which other packages can be installed (i.e. do not depend on φ).
In this case, we are obviously interested in determining the maximal set of
installable packages that do not conflict with φ and therefore eventually can be
granted installation.
In the present paper we provide a solution to these two problems in soft-
ware management through their formalization in a logic for negative trust.
Consistency-checking on contents is a natural basic way to interpret compu-
tational trust: if this is translated in the context of software management, trust
corresponds to a property obtained by installation validity as per Definition 1.
Negative trust seems therefore an appropriate functional counterpart to be ap-
plied to any software package which breaks such validity. Note that this can
notion of negative trust must allow to express the two cases mentioned above,
of trust removal (from the current profile) ad of trust denial (for external pack-
ages).
To express such operations, we are in need of a language which expresses
trust and its negation as functions on contents (i.e. software packages in the
present context), rather than as a relation between agents. To this aim the logic
(un)SecureND, introduced in Section 4, is an optimal tool. The logic allows to
5
