Signed-off-by: Pulluri.Shirija <Pulluri.Shirija@in.bosch.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

It installs an ELF binary in the directory that is not
architecture-specific on purpose.

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Pulluri Shirija <pulluri.shirija@in.bosch.com>

Signed-off-by: Pulluri Shirija <pulluri.shirija@in.bosch.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Dylan Aïssi <dylan.aissi@collabora.com>

Signed-off-by: Akshay M <M.Akshay@in.bosch.com>

Signed-off-by: Akshay M <M.Akshay@in.bosch.com>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Andrew Lee (李健秋) <ajqlee@debian.org>

We wish to use only the Apertis CI pipeline workflow to build source
packages from Apertis GitLab and then submit them to OBS.

For packages where Apertis is the upstream the simplest approach is to
set them up as native packages to avoid having to generate orig tarballs
and manage changes on top of them.

Signed-off-by: Andrew Lee (李健秋) <andrew.lee@collabora.co.uk>

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Newer hotdoc (0.10) introduced several breaking changes which cause the
documentation to be misbuilt, so let's explicitly depend on the old version.

Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

dh_apparmor setup debian package to reload AppArmor profiles on package
installation.

Fixes: https://phabricator.apertis.org/T5294



Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Andrej Shadura <andrew.shadura@collabora.co.uk>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Snapshots from build-snapshot have UNRELEASED in their changelogs,
so they are exempt from this check. The symbols file should be updated
while releasing the package.

Very similar to D3832.

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Differential Revision: https://phabricator.apertis.org/D6838

Debian Policy §8 requires packaging shared libraries like this.

In addition, move the libnewportiface.so symlink (the implementation
of -lnewportiface) to the -dev package: it is not needed at runtime.

Because libnewportiface0 and newport-dev both contain files that were
previously in the newport package, they need Breaks and Replaces on
older newport packages.

Signed-off-by: Simon McVittie <smcv@collabora.com>
Differential Revision: https://phabricator.apertis.org/D6837

Signed-off-by: Simon McVittie <smcv@collabora.com>

Differential Revision: https://phabricator.apertis.org/D6836

These are not strictly redundant because they apply to all object
paths, but we only expect legitimate clients of Newport to communicate
with the exported object paths below /org/apertis/Newport, so we no
longer need these rules.

Apertis: https://phabricator.apertis.org/T3995


Signed-off-by: Simon McVittie <smcv@collabora.com>

Differential Revision: https://phabricator.apertis.org/D6835

Ideally, we would want to allow arbitrary processes to be Newport's
client (meaning Newport can receive their method calls, and send
signals that they will receive), but not let Newport be a client of
arbitrary services (which would open up privilege escalation via
services like systemd --user if Newport gets compromised). However,
this isn't currently possible, because AppArmor D-Bus mediation
doesn't know about message types.

The closest we can currently get to this is to match by object path,
allowing Newport to receive method calls and emit signals on the
object paths that in practice only Newport will use.

We also allow unconfined tests and developer processes to call
arbitrary methods on us: they are unconfined, so they could call
those methods anyway by temporarily transitioning to a profile that
is already allowed to talk to us. This automatically allows one
requested reply per method call, without needing an explicit rule
in the AppArmor profile. However, we make this one asymmetric, so
that we don't allow Newport to send messages (in particular method
calls) to unconfined processes (in particular systemd --user).

We previously avoided looking at the message payload because we wanted
to avoid access controls that would not have been possible under kdbus,
but the kdbus project appears to be dead, and it isn't clear that its
symmetrical access-control model (A can talk to B iff B can talk to A)
was particularly realistic in practice due to issues like the ones we
have here.

Apertis: https://phabricator.apertis.org/T3995


Signed-off-by: Simon McVittie <smcv@collabora.com>

Differential Revision: https://phabricator.apertis.org/D6834