[Bug 2065088] Re: AppArmor profiles allowing userns not immediately active in 24.04 live image

[Simon McVittie]

> sadly yes, the init script has a bail out that stops loading policy on
the live cd

So am I understanding this correctly?

- everything in the live environment is effectively `unconfined`, and
before 24.04 this increased security exposure (no mitigations for
compromised/malicious apps) but could not break functionality (nothing
is forbidden by policy, so everything works)

- but since 24.04, `unconfined` has fewer privileges than e.g. `steam`
(it cannot create new user namespaces), so the extra security exposure
of userns is avoided, but some functionality is missing

This makes the live-image considerably less useful for the purpose I've
been using it for: as a clean-slate Ubuntu environment, where all
settings that were not manually changed are at their defaults, and
hacks/workarounds from one test cannot accidentally leak into other
tests.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065088

Title:
  AppArmor profiles allowing userns not immediately active in 24.04 live
  image

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065088/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065088] Re: AppArmor profiles allowing userns not immediately active in 24.04 live image

[Simon McVittie]

Installing from Valve's official steam-launcher .deb package runs into
the same problem. The same workaround works.

1. Boot an Ubuntu 24.04 live image, in a virtual machine with lots of RAM (I 
gave it 8G) so that it will have enough space on the root tmpfs to install 
Steam. Using Debian 12's libvirt and qemu, I found that virtio graphics didn't 
work, and used qxl as a workaround.
2. When prompted, choose a keyboard layout etc., and choose to "Try Ubuntu" 
rather than "Install Ubuntu".
3. Open a terminal
5. sudo apt update
4. Copy steam_latest.deb or steam-launcher_*.deb onto the machine somehow: in 
this test I was evaluating a new release that is not yet public, but I expect 
the same thing would happen with Valve's official .deb.
6. sudo apt install ./*.deb
7. steam
8. See a light grey progress bar "Steam setup / Updating Steam runtime 
environment...". Wait.
9. See a dark grey progress bar "Steam / Updating Steam... Downloading update 
(xxx of 465,450 KB)...". Wait.
10. Dark grey progress bar becomes "Steam / Updating Steam... Extracting 
package...". Wait.
11. Output in terminal shows "Restarting Steam by request...". Wait.

Expected result: same as in initial report

Actual result: same as in initial report

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065088

Title:
  AppArmor profiles allowing userns not immediately active in 24.04 live
  image

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065088/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065088] [NEW] AppArmor profiles allowing userns not immediately active in 24.04 live image

[Simon McVittie]

Public bug reported:

Side issue from . I saw this with Steam, but Ubuntu 24.04's AppArmor
setup for Steam is quite simple, so I suspect that the same thing might
happen for any of the other third-party software that needs an AppArmor
profile for
.

Steps to reproduce:

1. Boot an Ubuntu 24.04 live image, in a virtual machine with lots of RAM (I 
gave it 8G) so that it will have enough space on the root tmpfs to install 
Steam. Using Debian 12's libvirt and qemu, I found that virtio graphics didn't 
work, and used qxl as a workaround.
2. When prompted, choose a keyboard layout etc., and choose to "Try Ubuntu" 
rather than "Install Ubuntu".
3. Open a terminal
4. sudo dpkg --add-architecture i386
5. sudo apt update
6. sudo apt install steam (in this case steam is a transitional package with a 
dependency on steam-installer, both at version 1:1.0.0.79~ds-2)
7. steam
8. See a prompt warning me that Steam is proprietary binary-only software. 
Choose Install.
9. See a light grey progress bar "Steam setup / Updating Steam runtime 
environment...". Wait.
10. See a dark grey progress bar "Steam / Updating Steam... Downloading update 
(xxx of 465,450 KB)...". Wait.
11. Dark grey progress bar becomes "Steam / Updating Steam... Extracting 
package...". Wait.
12. Output in terminal shows "Restarting Steam by request...". Wait.

Expected result:

- /etc/apparmor.d/steam allows Steam to create new user namespaces, etc.
- Steam starts successfully

Actual result:

- A dialog box with "Error / Steam now requires user namespaces to be enabled"
- Audit log: apparmor="DENIED" operation="userns_create" class="namespace" 
info="Userns create restricted - failed to find unprivileged_userns profile" 
error=-13 profile="unconfined" pid=... comm="srt-bwrap" 
requested="userns_create" denied="userns_create" target="unprivileged_userns"

Workaround:

- Force Ubuntu's AppArmor profile for Steam to be reloaded: sudo 
apparmor_parser -Tr /etc/apparmor.d/steam
- Run steam again

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065088

Title:
  AppArmor profiles allowing userns not immediately active in 24.04 live
  image

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2065088/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2062406] Re: CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

[Simon McVittie]

This also affects focal, bionic, and older LTS suites.

If it's possible to update focal to 1.12.9 from the upstream 1.12.x
stable branch, that would also resolve LP: #2063034 and LP: #2063035.
There isn't much point in the upstream developers doing 1.12.x releases
if distributions aren't going to pick them up.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2062406

Title:
  CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2062406/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063034] [NEW] CVE-2023-28101: Metadata with ANSI control codes can cause misleading terminal output

[Simon McVittie]

*** This bug is a security vulnerability ***

Public security bug reported:

https://github.com/flatpak/flatpak/security/advisories/GHSA-h43h-fwqx-
mpp8

This was fixed in 1.15.4, 1.10.x >= 1.10.8, 1.12.x >= 1.12.8, 1.14.x >=
1.14.4.

At the time of writing, noble and mantic are OK, but jammy is
vulnerable, and focal and bionic are probably vulnerable too.

** Affects: flatpak (Ubuntu)
 Importance: Undecided
 Status: New

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-28101

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063034

Title:
  CVE-2023-28101: Metadata with ANSI control codes can cause misleading
  terminal output

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2063034/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063035] [NEW] CVE-2023-28100: TIOCLINUX can send commands outside sandbox if running on a virtual console

[Simon McVittie]

*** This bug is a security vulnerability ***

Public security bug reported:

https://github.com/flatpak/flatpak/security/advisories/GHSA-7qpw-3vjv-
xrqp

Fixed in 1.15.4, 1.10.x >= 1.10.8, 1.12.x >= 1.12.8, 1.14.x >= 1.14.4.
At the time of writing, mantic and noble are OK but jammy, focal and
bionic are likely to be vulnerable.

(This is a relatively low-impact vulnerability because it's unusual to
run flatpak from a Linux virtual console.)

** Affects: flatpak (Ubuntu)
 Importance: Undecided
 Status: New

** Information type changed from Private Security to Public Security

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2023-28100

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063035

Title:
  CVE-2023-28100: TIOCLINUX can send commands outside sandbox if running
  on a virtual console

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2063035/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2062956] Re: CVE-2024-32462 - Need to update to the last secure patch

[Simon McVittie]

*** This bug is a duplicate of bug 2062406 ***
https://bugs.launchpad.net/bugs/2062406

This is the same vulnerability as LP: #2062406.

** This bug has been marked a duplicate of bug 2062406
   CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2062956

Title:
  CVE-2024-32462 - Need to update to the last secure patch

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2062956/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2062406] Re: CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

[Simon McVittie]

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2024-32462

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2062406

Title:
  CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2062406/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2062406] [NEW] CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

[Simon McVittie]

*** This bug is a security vulnerability ***

Public security bug reported:

Upstream advisory:
https://github.com/flatpak/flatpak/security/advisories/GHSA-
phv6-cpc2-2fgj

If possible please sync 1.14.6-1 from Debian instead of backporting
fixes. That version only fixes the security issue and one other high-
visibility bug (app developer names showing in the CLI as though they
were the app's name).

** Affects: flatpak (Ubuntu)
 Importance: Undecided
 Status: New

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2062406

Title:
  CVE-2024-32462: Sandbox escape via RequestBackground portal and CWE-88

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/2062406/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1798967] Re: bubblewrap has wrong description after setuid bit was removed

[Simon McVittie]

This was fixed in 0.4.1-3 (2021).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1798967

Title:
  bubblewrap has wrong description after setuid bit was removed

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1798967/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976288] Re: testatomic segfaults on Ubuntu arm64 buildd

[Simon McVittie]

A workaround is present in 2.0.22+dfsg-4, but the fact that `testatomic`
crashes seems like a bug somewhere (SDL? Ubuntu's toolchain? Ubuntu's
buildds? ...) so I'm reopening this.

** Changed in: libsdl2 (Ubuntu)
   Status: Fix Released => New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976288

Title:
  testatomic segfaults on Ubuntu arm64 buildd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976288/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976288] Re: testatomic segfaults on Ubuntu arm64 buildd

[Simon McVittie]

As I had hoped, libsdl2_2.0.22+dfsg-4 in Debian is now running all the
tests (successfully), while libsdl2_2.0.22+dfsg-4~build1 in Ubuntu is
skipping the one that previously crashed on Ubuntu and running the rest.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976288

Title:
  testatomic segfaults on Ubuntu arm64 buildd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976288/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976288] Re: testatomic segfaults on Ubuntu arm64 buildd

[Simon McVittie]

libsdl2_2.0.22+dfsg-4 in Debian hopefully works around this crash, while
still having at least minimal test coverage on Ubuntu arm64.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976288

Title:
  testatomic segfaults on Ubuntu arm64 buildd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976288/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976288] Re: testatomic segfaults on Ubuntu arm64 buildd

[Simon McVittie]

I would prefer it if any tests that need to be skipped conditionally are
accompanied by a reference to a bug report (on the basis that a failing
test is technical debt, and technical debt is a bug), either in
Launchpad for workarounds for Ubuntu-specific issues, in the Debian BTS
for workarounds for issues affecting Debian or all Debian-derived
distros, or upstream.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976288

Title:
  testatomic segfaults on Ubuntu arm64 buildd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976288/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1976288] [NEW] testatomic segfaults on Ubuntu arm64 buildd

[Simon McVittie]

Public bug reported:

The 'testatomic' test-case crashes with a segmentation fault on Ubuntu
arm64 buildds, resulting in build-time test results being ignored (via a
change from Gianfranco Costamagna).

Is this a known problem with the Ubuntu buildds? If yes, is there a
timeline for when it can be resolved? In general we should expect to be
able to run most tests successfully on autobuilders.

I'm going to narrow this workaround down so that only testatomic is
skipped on Ubuntu arm64, so that we can get at least *some* test
coverage.

** Affects: libsdl2 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1976288

Title:
  testatomic segfaults on Ubuntu arm64 buildd

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1976288/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1957779] Re: Regression: GNOME-specific interfaces not available in main

[Simon McVittie]

The reason I didn't want to do that in Debian is that x-d-p-gnome
Recommends gnome-shell, and circular Recommends prevent unused packages
from being autoremoved.

In Debian, the gnome-core metapackage Depends on x-d-p-gnome. I think
ubuntu-desktop pulling it in as a Recommends is also appropriate.

The only other place I can think of that might be appropriate to add it
is to have gnome-session Recommends: x-d-p-gnome? That would probably be
better to change in Debian and pick up from there, rather than having it
be Ubuntu-specific.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957779

Title:
  Regression: GNOME-specific interfaces not available in main

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gtk/+bug/1957779/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1957779] Re: Regression: GNOME-specific interfaces not available in main

[Simon McVittie]

As a side note, if the Ubuntu maintainers of the x-d-p family need to
maintain a patched x-d-p or x-d-p-gtk, you're welcome to use `ubuntu/*`
branches in its Debian git repository, similar to how the GNOME team
handles their packages that need to be patched in Ubuntu. If this would
be useful, please let me know who would need access.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957779

Title:
  Regression: GNOME-specific interfaces not available in main

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gtk/+bug/1957779/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1957779] [NEW] Regression: GNOME-specific interfaces not available in main

[Simon McVittie]

Public bug reported:

Historically, xdg-desktop-portal-gtk had two roles:

* Generic GTK implementations of various interfaces, suitable for all
GTK desktops (GNOME, XFCE, etc.) and also as a fallback implementation
for desktops that do not have something more "native". Interfaces:
Access, Account, AppChooser, Email, FileChooser, Inhibit, Lockdown,
Notification, Print, Settings.

* GNOME-specific implementations of various interfaces, suitable for
GNOME Shell only (and mybe Budgie, but not XFCE, MATE or Cinnamon
because they do not use gnome-settings-daemon or a libmutter-based
compositor). Interfaces: Background, Remote Desktop, Screencast,
Screenshot, Wallpaper.

In 1.10.0-2, these roles were separated:

* Generic GTK stuff is still in x-d-p-gtk

* GNOME-specific functionality has moved to x-d-p-gnome, a separate
source package, which is installed by the gnome-core metapackage in
Debian

In Ubuntu, x-d-p-gtk is in main but x-d-p-gnome is in universe (and
presumably not installed by default). This means that users of Snap and
Flatpak apps will not have access to the affected interfaces via xdg-
desktop-portal any more, which is a regression, particularly if using
native Wayland rather than X11.

There are two possible solutions to this:

1. Move x-d-p-gnome to main, and install it by default (in any
installation that has GNOME Shell). GNOME upstream consider it to be
part of a complete GNOME desktop. This is the long-term solution.

2. Patch x-d-p-gtk to reinstate the build-dependencies that were
disabled in 1.10.0-2, and re-enable them in d/rules. This provides an
older version of these interfaces, which is no longer routinely tested
by upstream or Debian. This solution will probably stop working in a
future release when these interfaces are removed completely.

I would recommend the first solution for Ubuntu 22.04 LTS.

I am probably going to use the second solution in Debian bullseye-
backports, and if Ubuntu people want to maintain a backport of x-d-p-gtk
to older suites like focal, it's probably the right thing to do for
those too.

** Affects: xdg-desktop-portal-gtk (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957779

Title:
  Regression: GNOME-specific interfaces not available in main

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xdg-desktop-portal-gtk/+bug/1957779/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1957716] Re: Update for CVE-2021-43860 and second github advisory

[Simon McVittie]

The patches for CVE-2021-43860 (aka GHSA-qpjc-vq3c-572j) include some
test-cases, which are run during build and as part of the autopkgtest.

There is currently no automated test coverage for GHSA-8ch7-5j3h-g4fx.

If possible I would recommend upgrading to 1.12.3 and 1.10.6, rather
than backporting individual commits. The stable-branches are
specifically there to be used by downstream distributions that want
bugfix-only updates.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1957716

Title:
  Update for CVE-2021-43860 and second github advisory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1957716/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1946578] Re: Placeholder for CVE-2021-41133

[Simon McVittie]

I think we have the regressions under control now.

https://salsa.debian.org/debian/flatpak/-/commits/wip/1.10.x/ is
packaging of 1.10.5 aimed at inclusion in Debian 11, including one
post-1.10.5 bug fix https://github.com/flatpak/flatpak/pull/4461 which
will hopefully be included in 1.10.6. I'm waiting for an opinion from
the Debian security team. For release series that are already based on
1.10.x, I'd recommend basing your releases on that version.

For full effectiveness, you'll want libseccomp 2.5.2, with which we can
block all the syscalls we identified as undesired, including
`mount_setattr()`.

Failing that, libseccomp 2.5.0 is sufficient to be able to block
`clone3()`, which I think should prevent a successful exploit: by
preventing creation of new user namespaces, it stops a malicious or
compromised Flatpak app from getting CAP_SYS_ADMIN in a new user
namespace, which it would need if it wanted to be able to invoke
`mount_setattr()`.

For release series that use 1.6.x or 1.0.x, Flatpak upstream does not
support those branches any more and will not make new releases. If
someone wants to get involved upstream, I'd accept MRs against those
branches as a coordination point for "if you're stuck on this branch,
here's what other distros are doing...", similar to what I'm doing for
1.2.x on https://github.com/flatpak/flatpak/pull/4455.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1946578

Title:
  Placeholder for CVE-2021-41133

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1946578/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1943480] Re: flatpak installation permission requirements different from ubuntu software

[Simon McVittie]

With Debian maintainer hat on, I'm willing to have a limited amount of
DEB_VENDOR conditionalization in the Debian packaging, like the way we
used to compile xdg-desktop-portal with --disable-pipewire before
pipewire was available in Ubuntu main.

However, I draw the line at applying Ubuntu-specific patches in Debian;
if Ubuntu wants those, then branching the packaging will be necessary.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1943480

Title:
  flatpak installation permission requirements different from ubuntu
  software

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1943480/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1943480] Re: flatpak installation permission requirements different from ubuntu software

[Simon McVittie]

I would recommend that Ubuntu either uses the Debian package as-is, or
branches from the Debian packaging to apply whatever divergence is
desired. I'd be happy to let Ubuntu maintainers of flatpak use the
`ubuntu/*` namespace on Salsa for this, similar to how gnome-shell is
packaged.

Obviously I'm only a Debian and upstream maintainer of Flatpak, and not
an Ubuntu developer; if Ubuntu people want to diverge, that's their
choice to make, although I would encourage prospective Ubuntu
maintainers to consider the maintenance cost of divergence before
diverging.

> - unix 'wheel' group users can install and remove packages from configured
>  flatpak remotes, without password

Where are you getting this from? From upstream, or from Ubuntu
packaging?

The upstream default is the wheel group, but the Debian packaging
configures flatpak `--with-privileged-group=sudo`, which should mean
that the privileged (root-equivalent) group is `sudo` rather than
`wheel`. I would hope that Ubuntu inherits that configuration change.

> As such, installation of new apps via flatpak should use polkit to authorise 
> the transaction -
> whilst upgrades should not.

Deleting the custom polkit policy
(/var/lib/polkit-1/localauthority/10-vendor.d/org.freedesktop.Flatpak.pkla
and/or /usr/share/polkit-1/rules.d/org.freedesktop.Flatpak.rules,
depending which polkit version Ubuntu is using) might be enough to get
this behaviour. Please see
/usr/share/polkit-1/actions/org.freedesktop.Flatpak.policy for details
of what will happen if those files are deleted.

Please bear in mind that upgrading an app might require installing a new
runtime for it to run on (for example, upgrading org.gnome.Recipes might
switch its required runtime from org.gnome.Platform//40  to
org.gnome.Platform//41, or upgrading com.valvesoftware.SteamLink might
switch its required runtime from org.freedesktop.Platform//20.08 to
org.freedesktop.Platform//21.08), so even if
org.freedesktop.Flatpak.app-install requires authentication, it might be
desirable for org.freedesktop.Flatpak.runtime-install to not require
authentication.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1943480

Title:
  flatpak installation permission requirements different from ubuntu
  software

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1943480/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1857810] Re: osspd no longer works: ERR: failed to connect context, state=5 (Bad state)

[Simon McVittie]

This is the same issue as https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=986662 and is fixed in newer versions of the
Debian package.

> crackling/popping noises

On Debian, I get similar distortion with the fixed PulseAudio backend
too (but at least it's usable).

** Bug watch added: Debian Bug tracker #986662
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986662

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1857810

Title:
  osspd no longer works: ERR: failed to connect context, state=5 (Bad
  state)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/osspd/+bug/1857810/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1801814] Re: Environment overwrites XDG_DATA_DIRS

[Simon McVittie]

This is believed to be fixed by version 1.8.1-1, which converts the gdm
env.d fragment into an example file (moving it from usr/share/gdm/env.d
to usr/share/doc/flatpak/examples/etc/gdm3/env.d). If Ubuntu developers
want to backport that change to 20.04, please see commit b634ea2a in the
Debian packaging.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1801814

Title:
  Environment overwrites XDG_DATA_DIRS

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1801814/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1876717] Re: CVE-2020-11651 and CVE-2020-11652

[Simon McVittie]

** Bug watch added: Debian Bug tracker #959684
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959684

** Also affects: salt (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959684
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1876717

Title:
  CVE-2020-11651 and CVE-2020-11652

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/salt/+bug/1876717/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 917757] Re: cheese crashed with SIGSEGV in cheese_camera_set_device_by_dev_uuid()

[Simon McVittie]

** Bug watch added: bugzilla.gnome.org/ #677544
   https://bugzilla.gnome.org/show_bug.cgi?id=677544

** Changed in: cheese
   Importance: Critical => Unknown

** Changed in: cheese
   Status: Invalid => Unknown

** Changed in: cheese
 Remote watch: GNOME Bug Tracker #671201 => bugzilla.gnome.org/ #677544

** Bug watch added: Debian Bug tracker #685436
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685436

** Also affects: cheese (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685436
   Importance: Unknown
   Status: Unknown

** Changed in: cheese (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/917757

Title:
  cheese crashed with SIGSEGV in cheese_camera_set_device_by_dev_uuid()

To manage notifications about this bug go to:
https://bugs.launchpad.net/cheese/+bug/917757/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1838890] [NEW] Suspected memory leak in xenial backport of fix for CVE-2019-13012

[Simon McVittie]

Public bug reported:

(This is only from source code inspection, not tested in real use - I
don't actually use Ubuntu.)

The upstream fix for CVE-2019-13012 included this change:

-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+  g_mkdir_with_parents (g_file_peek_path (kfsb->dir), 0700);

However, g_file_peek_path() was only introduced in GLib 2.56. The
backport in the xenial package has this instead:

-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+  g_mkdir_with_parents (g_file_get_path (kfsb->dir), 0700);

This is not equivalent. The difference between g_file_peek_path() and
the older g_file_get_path() is that g_file_get_path() makes a copy,
which must be freed with g_free() after use. As a result, there is now a
memory leak.

A non-leaky backport would look something like this, which is what I've
done in a proposed backport for Debian 9 'stretch':

+ char *dir;
...
-  g_file_make_directory_with_parents (kfsb->dir, NULL, NULL);
+  dir = g_file_get_path (kfsb->dir);
+  g_mkdir_with_parents (dir, 0700);
+  g_free (dir);

** Affects: glib2.0 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838890

Title:
  Suspected memory leak in xenial backport of fix for CVE-2019-13012

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/1838890/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 336634]

[Simon McVittie]

See also Bug #105572.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/336634

Title:
  libxxf86vm-dev should depend on libxext-dev

To manage notifications about this bug go to:
https://bugs.launchpad.net/pkg-config/+bug/336634/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1784391] [NEW] Please remove python-mmkeys from archive

[Simon McVittie]

Public bug reported:

sonata 1.7~b1 dropped the python-mmkeys binary package, which is
preventing it from migrating from cosmic-proposed to cosmic. Please ask
the Ubuntu archive administrators to do the equivalent of the removal
that solved https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898413 so
it can migrate.

** Affects: sonata (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1784391

Title:
  Please remove python-mmkeys from archive

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sonata/+bug/1784391/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1779667] Re: Unlocking existing session yields black screen. Closing session does not help as affected user cannot open a successful X session until next reboot. Other users are ok.

[Simon McVittie]

Please attach anything vaguely relevant-looking from the system log
(systemd Journal if you use systemd, or /var/log/syslog). The bug will
probably be somewhere in the vicinity of logind, PAM, dbus-daemon,
lightdm, X or XFCE, or possibly graphics drivers in the kernel (which
have been known to lock up during fast-user-switching), but without
looking at the log it's impossible to say which.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1779667

Title:
  Unlocking existing session yields black screen. Closing session does
  not help as affected user cannot open a successful X session until
  next reboot. Other users are ok.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1779667/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1038434] Re: kupfer.py crashed with SIGSEGV

[Simon McVittie]

** Changed in: dbus-python (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1038434

Title:
  kupfer.py crashed with SIGSEGV

To manage notifications about this bug go to:
https://bugs.launchpad.net/kupfer/+bug/1038434/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1165742] Re: Synctex plugin was not built in raring

[Simon McVittie]

** Changed in: dbus-python (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1165742

Title:
  Synctex plugin was not built in raring

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus-python/+bug/1165742/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1750382] Re: please roll back to 0.10.x stable branch or confirm use of 0.11.x for bionic

[Simon McVittie]

OK, so there is no longer any reason for me to avoid 0.11 in Debian
unstable? Thanks for checking. If that's your final answer, this bug can
be closed.

If you are going with 0.11.x, please consider syncing 0.11.3 (from
experimental for now).

It is possible that the stable branch resulting from the 0.11.x series
(what we have called "0.12" in this discussion) will in fact be labelled
1.0.x, but either way it'll be a stabilized version of 0.11.x, like the
difference between GLib 2.55.x and 2.56.x.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750382

Title:
  please roll back to 0.10.x stable branch or confirm use of 0.11.x for
  bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1750382/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1750382] Re: please roll back to 0.10.x stable branch or confirm use of 0.11.x for bionic

[Simon McVittie]

> i *think* the even ones are considered LTS releases, not necessarily
> that the odd ones are unstable

0.10.x being described as a stable-branch is about the meaning of
"stable/unstable" that could be paraphrased as "doesn't change a
lot/does change a lot" (just like the Debian stable and unstable
suites). It is not about "works/doesn't work". 0.11.x works fine, and
(in general) so does Debian unstable - but they are moving targets, with
frequent changes, some of them large.

If you follow the 0.11.x branch, you have to be prepared for the
possibility that the upgrade from (for example) 0.11.3 to 0.11.4 might
contain intrusive changes (a large diffstat, new features, perhaps new
dependencies, perhaps an elevated risk of regressions). If it does, and
it's too large a change for your distribution's stable release managers
to be willing to apply it as a SRU, then subsequent releases from the
0.11.x branch would not be eligible for SRU either, even if they fix
security vulnerabilities or other major bugs. Your only options would be
to backport individual changes, or reconsider the policy for the size of
changes that is acceptable; there would probably not be a 0.11.3.1
upstream release that you can import, because upstream will have moved
on to later versions already.

> starting at 0.11 simplifies the fact that the document-portal was ripped
> out and moved to xdg-desktop-portal

This is not directly relevant for Debian (and hence Ubuntu, if Ubuntu
syncs versions from Debian), because in Debian I already did that
transition with the move from Flatpak 0.10.3 to 0.10.4.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750382

Title:
  please roll back to 0.10.x stable branch or confirm use of 0.11.x for
  bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1750382/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1750382] Re: please roll back to 0.10.x stable branch or confirm use of 0.11.x for bionic

[Simon McVittie]

I am not an Ubuntu developer, but my understanding of "new upstream
micro-releases" would be that it covers releases with targeted bugfixes,
like GLib 2.54.3 to 2.54.4, dbus 1.12.2 to 1.12.4, or flatpak 0.10.3 to
0.10.4. In some cases Flatpak 0.10.x also contains minor new features if
they are necessary for forwards compatibility. I have used the Debian
equivalent of SRUs (stable updates) to push new micro versions of dbus
and flatpak into Debian stable, which is analogous to Ubuntu LTS, and I
intend to continue to do so. If you want to benefit from my work in that
direction (where it happens to align) please set up your Flatpak version
to make that straightforward :-)

If your stable release managers would allow making an exception to the
usual rules and updating Flatpak across versions that add significant
new feature work (0.8 to 0.9+, or 0.9.x to 0.10) then you might as well
go ahead with 0.11.x, but definitely talk to them first.

What I want to avoid is that Flatpak in bionic is frozen at some random
development release for 5 years, and cannot go forward to a subsequent
release from the same branch (or a 0.12.x or 1.0.x stable branch)
because the changes are considered to be too large, like the way old
Ubuntu releases shipped some random version of dbus 1.3.x and weren't
allowed to advance to the 1.4.x stable branch. In that scenario, I
suspect that the changes allowed to Flatpak by the SRU policy would be
*more* restrictive than if you'd just shipped 0.10.x (no targeted fixes
for non-security bugs, and no changes to improve forward compatibility,
even when upstream consider them important enough to backport into
0.10.x).

I also don't think upstream developers with a stable/development
branching structure can be expected to provide security support for
development branches, so if you got stuck on a development release,
backporting security patches would be entirely up to you.

It's up to you, and I don't intend to tell you how to run your distro,
but I was surprised to see 0.11 land at this point in the release cycle!

(If you do want 0.11.x, 0.11.3 is now in experimental and available for
sync.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750382

Title:
  please roll back to 0.10.x stable branch or confirm use of 0.11.x for
  bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1750382/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1750382] Re: please roll back to 0.10.x stable branch or confirm use of 0.11.x for bionic

[Simon McVittie]

I'm also packaging 0.11.3 now for experimental, so you might want to
sync that. Pull requests welcome at
https://salsa.debian.org/debian/flatpak if you have packaging changes
that are not inherently Ubuntu-specific.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750382

Title:
  please roll back to 0.10.x stable branch or confirm use of 0.11.x for
  bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1750382/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1750382] [NEW] please roll back to 0.10.x stable branch or confirm use of 0.11.x for bionic

[Simon McVittie]

Public bug reported:

Flatpak 0.10.x is a stable branch and I am currently tracking it in
Debian. I had intended to move to the 0.11.x development branch, but
only after Ubuntu 18.04 LTS freezes, on the assumption that you would
want to use a stable branch in your LTS release. With the latest
versions in unstable, flatpak >= 0.10.4 can be used with xdg-desktop-
portal >= 0.10 (and 0.11.x is also available from Debian, but only in
experimental).

However, bionic has now skipped ahead to flatpak 0.11.1, possibly from a
mistaken belief that this was necessary to be able to pick up xdg-
desktop-portal 0.10. This seems an odd thing to do right before an LTS
release, and it isn't what I'd have done; but if that's what you want,
go ahead.

I spoke to seb128 on IRC, and he wondered whether rolling back to 0.10.4
would be a better thing to do.

Please decide whether bionic will ship with 0.10.x or with 0.11.x and
tell flatpak AT packages DOT debian DOT org your decision. If 0.10.x,
I'll continue to upload those versions to Debian until bionic freezes,
and only diverge after your freeze date. If 0.11.x, I'll land the
experimental version into unstable sooner.

** Affects: flatpak (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1750382

Title:
  please roll back to 0.10.x stable branch or confirm use of 0.11.x for
  bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flatpak/+bug/1750382/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1709164] Re: [MIR] bubblewrap

[Simon McVittie]

> I woudl split them in a separate package as they don't need to be
installed by default, but it's up to you.

Sorry, I am not willing to put this package through the Debian NEW queue
just to split out a few KB of examples into a separate binary package,
and I suspect the ftp team would take a dim view of this: the size of
the archive metadata required to describe that binary package would the
same order of magnitude as the size of the package itself. If they are
considered to be a serious problem for some reason, then I'll delete
them altogether, and just patch in the README.

The demos are re-included via debian/dist/ (older versions) or
debian/patches/dist/ (newer) because I was looking at packaging a git
snapshot in experimental, and happened to notice that they are shipped
upstream but were accidentally not included in tarballs. I also
contributed a patch upstream to include them in `make dist`, and that
patch has been merged.

I believe flatpak.bpf is a snapshot of the seccomp filter that was set
up by some random older version of Flatpak, and accompanies flatpak-
run.sh to make flatpak-run.sh more closely resemble what Flatpak
actually does. bubblewrap takes seccomp filters as input in binary form
rather than building them using libseccomp, because bubblewrap is
(initially) highly privileged, so library dependencies are minimized to
reduce attack surface; instead, the unprivileged Flatpak binary links
libseccomp and constructs the filter itself.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1709164

Title:
  [MIR] bubblewrap

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1709164/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1709164] Re: FFe: [MIR] bubblewrap

[Simon McVittie]

> dh_auto_test runs the build tests but they appear to be set as SKIP
upstream.

They are automatically skipped if you are building in an environment
where the simplest possible use of bwrap (bind-mounting / over / and
running /bin/true) doesn't work, which unfortunately includes all
official Debian and Ubuntu buildds.

On Debian, one factor is that Debian's kernel doesn't allow creation of
unprivileged user namespaces by default, which means bwrap needs to be
setuid to work, and in a buildd environment the just-built bwrap is not
yet setuid. I'm not sure whether this applies on Ubuntu.

Another factor is that we can't typically run bwrap inside a container,
and I'm not sure that running it inside a chroot works either.

In general the bubblewrap/flatpak stack will have to be tested via
autopkgtest or equivalent - expecting container stuff to work correctly
at build-time is not really very feasible.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1709164

Title:
  FFe: [MIR] bubblewrap

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bubblewrap/+bug/1709164/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1692582] Re: RFE: dbus AppArmor mediation matching by message type

[Simon McVittie]

> What time frame are you looking for to land fixes for this

I don't have a specific timeline for this, I just wanted to raise it as
a missing feature before I forgot about it.

I think the project that I wanted this for might be able to work around
the missing feature with rules like

dbus (send,receive) bus=session path=/com/example/MyService/**,
dbus receive bus=session peer=(label=unconfined),

so that unconfined developer/test processes can call Ping() and
Introspect(), all processes can call the service's methods and receive
its signals, but the service can't call methods on (the interesting
object paths of) more-privileged processes like systemd.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1692582

Title:
  RFE: dbus AppArmor mediation matching by message type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1692582] Re: RFE: dbus AppArmor mediation matching by message type

[Simon McVittie]

> 1. the label name on a service does not have to match its executable
name so an executable could be labeled with a more generic profile

Sure, but I'm not sure how this helps me to achieve what I'm aiming for,
which is:

 privileged
anything ---> my service ---X - > processes
 (systemd?)

where method calls go in the direction of the arrow, broadcast signals
go in the opposite direction, and the X indicates being blocked.

If all I want is to allow my-client-app to be a client of my-service, I
can already do:

profile /usr/bin/my-service {
  ...
  dbus (send,receive) bus=session,
}

profile /usr/bin/my-client-app {
  ...
  dbus (send,receive) bus=session peer=(label=/usr/bin/my-service),
}

but then my-service is also allowed to send method calls to every other
session service, including systemd --user (which in practice is
unconfined) - I've enabled the left hand side of the diagram above, but
not blocked the right hand side.

I could also do something like

profile foobar-service {   # implemented by my-service
  ...
  dbus (send,receive) bus=session peer=(label=*_foobar-client),
}

profile app-123_foobar-client {
  ...
  dbus (send,receive) bus=session peer=(label=foobar-service),
}

to restrict the profiles to being about the left hand side of my
diagram, but that doesn't seem like it really scales when a particular
app might be a client of lots of services.

Without distinguishing between messages by type or payload, it's also
difficult to let unconfined processes use my service as clients (the
platform I'm working on uses this a lot, for regression tests), without
also letting my service (if it gets compromised) use unconfined services
like systemd as a client. So, getting the left part but blocking the
right part in this special case:

unconfined  unconfined
utility or ---> my service ---X - > service
automated test  (systemd)

When I say "is a client of" I'm referring to the common pattern where n
clients all call methods on a service and receive signals from that
service, like the way GNOME Music and GNOME Documents are clients of
Tracker, and Empathy and Polari are clients of Telepathy Mission
Control.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1692582

Title:
  RFE: dbus AppArmor mediation matching by message type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1692582] Re: RFE: dbus AppArmor mediation matching by message type

[Simon McVittie]

If I'm reading the AppArmor user-space source code correctly, if
backwards compatibility wasn't a concern then this could be achieved by
adding an additional user-defined field to vec in
dbus_rule::gen_policy_re(Profile&) and passing the new number of fields
to add_rule_vec(), then adding that same field to the queries built by
dbus-daemon in bus/apparmor.c build_message_query().

Unfortunately, again if I'm reading correctly, the query works by
building a long string with embedded \0 bytes, then matching it against
a DFA representing a single long regular expression that also has
embedded \0 bytes - if true, this would mean the number of fields can't
usefully be varied.

If extensibility is desired, I think the ideal thing might be if extra
fields in the query were ignored (always match) and extra fields in the
rule were compared as though the query had an empty string at that point
in the vector, but I don't know how feasible that would be.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1692582

Title:
  RFE: dbus AppArmor mediation matching by message type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1692582] [NEW] RFE: dbus AppArmor mediation matching by message type

[Simon McVittie]

Public bug reported:

Suppose you're writing an AppArmor profile for a D-Bus service like
Tracker. The service might get compromised (perhaps it's network-facing)
so you don't want it to be able to act as a client of privileged
processes like systemd --user. However, imagine you do want arbitrary
third-party "apps" to be allowed to use the service if they have
appropriate rules in their own AppArmor profiles.

One reasonably natural way to encode this without tightly coupling the
service and its clients would be:

profile /usr/bin/my-service {
  ...
  dbus send bus=session type=signal,
  dbus receive bus=session type=method_call,
}

profile /usr/bin/my-client-app {
  ...
  dbus (send,receive) bus=session peer=(label=/usr/bin/my-service),
}

However, the AppArmor integration in src:dbus and the rule parser in
src:apparmor don't allow this: they match fine-grained information like
the method name and object path, but have no concept of message types.
This seems backwards: I only expect the object path to be useful in very
rare/niche cases, but the message type is "larger" and more important
than anything else from the message payload.

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1692582

Title:
  RFE: dbus AppArmor mediation matching by message type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1692582/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1658606] Re: Alsa-lib 1.1.3-1 puls in python2.7 (Zepus dev)

[Simon McVittie]

** Bug watch added: Debian Bug tracker #852281
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852281

** Also affects: alsa-lib (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852281
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1658606

Title:
  Alsa-lib 1.1.3-1 puls in python2.7 (Zepus dev)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/alsa-lib/+bug/1658606/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1507469] Re: Evince's Apparmour profile prevents opening docs from other apps under Wayland

[Simon McVittie]

There is now an , which is #include'd by
. It includes weston-shared, but not the Wayland
socket itself.

I suspect a better rule for that would be:

owner /run/user/*/wayland-[0-9]* rw,

so that the numbered sockets that are conventionally used are matched
more precisely.

The complete set of possible fd-passed shared-memory backing files is
more like:

owner /run/user/*/{mesa,mutter,sdl,weston,xwayland}-shared-* rw,

because the Wayland code to create an anonymous backing file for shared
memory has been copied and pasted all over the place, with some
instances changing the name.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1507469

Title:
  Evince's Apparmour profile prevents opening docs from other apps under
  Wayland

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1507469/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Simon McVittie]

... er, that should be, I have some more ideas for testing on
.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1591411

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1591411/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Simon McVittie]

If you can reproduce this issue and you have an expendable machine or
container to test it on, I have some more ideas on Bug #95263.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1591411

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1591411/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Simon McVittie]

I have not been able to reproduce this on a Debian (jessie or sid) or
Ubuntu (xenial) virtual machine prepared according to the instructions
in autopkgtest-virt-qemu(1), even after reducing the pending_fd_timeout
limit from 15 (2.5 minutes) to 150 (150ms) with this configuration
in /etc/dbus-1/system-local.conf:


  150


This is with 4 parallel loops repeatedly logging in via ssh, currently
at around 280 logins each.

Is there something special that is needed in the OS image to exhibit
this failure mode?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1591411

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1591411/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 792085] Re: Automatic remount of safely removed usb 3.0 drive

[Simon McVittie]

> Dear udisks developers (Martin Pitt, Tom Yan, Simon McVittie, Kylie
McClain, Mike Frysinger, Mathieu Trudel-Lapierre, Peter Hatina, Phillip
Susi)!

No, this is not appropriate. It is ridiculous to assume that anyone who
has ever contributed to a project is a maintainer for that project,
responsible for that project, or responsible for fixing your favourite
bug (even if it is common and serious). If that was how it worked,
nobody rational would ever contribute anything.

If you want to pay someone to be responsible for fixing your favourite
bug, various companies offer support contracts. Otherwise, those who do
the work (in this case neither you nor me) set their own priorities.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/792085

Title:
  Automatic remount of safely removed usb 3.0 drive

To manage notifications about this bug go to:
https://bugs.launchpad.net/nautilus/+bug/792085/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay

[Simon McVittie]

> I am still not 100% sure if it is considered ready for prime time

As far as I can tell, Lennart's proposed patch on fd.o #95263 would
reintroduce CVE-2014-3637 (fd.o #80559), a denial of service security
vulnerability.

** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2014-3637

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1591411

Title:
  systemd-logind must be restarted every ~1000 SSH logins to prevent a
  ~25 second delay

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1591411/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1590411] Re: Sync flatpak 0.6.4-1 (universe) from Debian experimental (main)

[Simon McVittie]

Flatpak is in experimental because, until very recently, OSTree was in
experimental. I have since uploaded OSTree to unstable by removing the
more controversial bits (integration with grub, dracut and systemd for
the boot process, which I cannot actually test yet: see
 and
).

The next Flatpak upload, 0.6.5-1, will likely be tomorrow and target
unstable. The upstream version already exists, but I wanted to sort out
some test failures before uploading. That version also links flatpak-
bwrap with -lselinux more correctly, which might fix a FTBFS with
Ubuntu's more pedantic linker.

I would suggest waiting for 0.6.5-1 tbh, particularly if you are auto-
syncing from unstable.

** Bug watch added: Debian Bug tracker #824649
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824649

** Bug watch added: Debian Bug tracker #824650
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824650

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1590411

Title:
  Sync flatpak 0.6.4-1 (universe) from Debian experimental (main)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+bug/1590411/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1544874] [NEW] dbus.user-session.upstart could avoid mktemp

[Simon McVittie]

Public bug reported:

While investigating a separate bug I happened to look at dbus.user-
session.upstart, and noticed that it is somewhat more complex than it
needs to be.

> pre-start script
> DBUS_SESSION_BUS_ADDRESS=unix:abstract=$(mktemp -u /tmp/dbus-XX)
> initctl set-env DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
> end script
>
>
> exec dbus-daemon --fork --session --address="$DBUS_SESSION_BUS_ADDRESS"

One obvious simplification you could use here would be to ask dbus-
daemon to listen on an arbitrarily selected abstract AF_UNIX address and
tell you which one it used. In principle libdbus could have a retry loop
to try multiple possibilities if the one it selects first is in use
(which this use of mktemp obviously won't do); at the moment it doesn't,
because the probability of a successful DoS by creating lots of abstract
sockets is low (approximately n in 3e15, where n is the number of
sockets created by an attacker), but I'd review a patch to dbus/dbus-
server-unix.c if someone wanted to add that retry loop.

That would look something like this (please interpret this as pseudocode
rather than a proposed patch, I don't actually know Upstart syntax):

exec script
# the default listening address is equivalent to 
--address=unix:tmpdir=/tmp
dbus-daemon --fork --session --print-address=5 
5>"$XDG_RUNTIME_DIR/dbus-session"
end script

post-start script
DBUS_SESSION_BUS_ADDRESS="$(cat "$XDG_RUNTIME_DIR/dbus-session")"
initctl set-env --global 
DBUS_SESSION_BUS_ADDRESS="$DBUS_SESSION_BUS_ADDRESS"
initctl notify-dbus-address "$DBUS_SESSION_BUS_ADDRESS"
end script

which is already somewhat simpler. This would also have the advantage
that the advertised address would contain the bus's GUID like it does
with traditional dbus-launch, meaning that dbus_connection_open() would
work ().

However, since the current script only seems to support one dbus-daemon
per $XDG_RUNTIME_DIR anyway, there's little point in using mktemp or
unix:tmpdir: the job could instead force a specific address, like the
systemd unit in dbus-user-session does. Modern libdbus (1.10+) and GDBus
(2.45.3+) will try $XDG_RUNTIME_DIR/bus if there is no
DBUS_SESSION_BUS_ADDRESS, so setting the DBUS_SESSION_BUS_ADDRESS is
really only there to support reimplementations like dbus-sharp.

exec dbus-daemon --fork --session --address="unix:path=$XDG_RUNTIME_DIR/bus"
post-start initctl set-env --global 
DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/bus"
post-start initctl notify-dbus-address "unix:path=$XDG_RUNTIME_DIR/bus"

(This could be combined with --print-address if you want to know the
full address with the guid.)

Or, if the intention is to support multiple login sessions per user-
session (see  for terminology), the Upstart job could
force the bus to be "$XDG_RUNTIME_DIR/session-$XDG_SESSION_ID/bus" or
something.

** Affects: dbus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1544874

Title:
  dbus.user-session.upstart could avoid mktemp

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1544874/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1250668] Re: upstart session for dbus has hard coded .cache directory

[Simon McVittie]

> far more complicated than it needs to be

That may have been overstating it; in the absence of systemd-style
socket activation, there's a limit to how much it can be simplified
without having things try to connect to dbus-daemon before it's running
:-(

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1250668

Title:
  upstart session for dbus has hard coded .cache directory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1250668/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1250668] Re: upstart session for dbus has hard coded .cache directory

[Simon McVittie]

As of dbus/1.10.6-1ubuntu2 (the relevant change seems to have been in
1.8.12-1ubuntu1), the Upstart job creates that directory but then
doesn't do anything with it, because the session bus address is now
stored in XDG_RUNTIME_DIR.

This is one of several ways in which the Upstart job is far more
complicated than it needs to be, for which I'll open a separate bug.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1250668

Title:
  upstart session for dbus has hard coded .cache directory

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1250668/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1508697] Re: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id

[Simon McVittie]

> systemd doesn't inself create /etc/machine-id when missing, which it
should.

I think the solution to "my system-imaging setup isn't working" is to
get that bug (presumably a systemd bug?) fixed - this one is rather
minor by comparison. Do you have a correct bug# for it?

> I've put a lot of effort into making sure things that should be unique
between machines, things that are unique when you do a manual Ubuntu
install, are actually unique when we image a system.

Yeah, the list of things that should be unique has changed over time,
unfortunately. I hope that future software needing a unique machine ID
will just use /etc/machine-id, but D-Bus is older than systemd, so we
didn't have that option at the time. Now /var/lib/dbus/machine-id needs
to continue to exist, because some third party software depends on it,
but libdbus doesn't actually rely on it any more - it will try reading
both locations.

> After all, tools must already get along with a symlink due to the
tmpfiles.d

Be a bit careful here... things must cope with /var/lib/dbus/machine-id
being a symlink to /etc/machine-id *if we are booting with systemd*. If
the init system is sysvinit or Upstart (still supported in Debian) then
nothing guarantees there will ever be a /etc/machine-id.

However, systemd doesn't delete /etc/machine-id on purge, so after one
has been created, I think it's guaranteed to stay.

I'd be happy to review a patch upstream that made
_dbus_read_local_machine_uuid() with create_if_not_found=TRUE (i.e. the
implementation of dbus-uuidgen --ensure) symlink the machine ID rather
than copying it.

Alternatively, the postinst could create the symlink if /etc/machine-id
exists and has syntactically valid contents, or run dbus-uuidgen
--ensure if not.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508697

Title:
  dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-
  id

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1508697] Re: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id

[Simon McVittie]

That situation should never arise, because if the symlink exists, then
it was created by a successful boot with systemd sometime in the past;
systemd's API is that it guarantees to create /etc/machine-id before
running third-party code; and systemd never deletes the machine ID after
it has created one.

The ideal behaviour would be for dbus-uuidgen to replace the symlink
with a newly generated plain file, I think. I'd be happy to review a
patch (on freedesktop.org Bugzilla please) if that isn't already what it
does.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508697

Title:
  dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-
  id

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1508766] Re: /etc/machine-id not created if missing

[Simon McVittie]

I'm surprised the root filesystem is read-only at the point where
systemd starts. Isn't it remounted rw by the initramfs? (It is in
Debian.)

>From context on lp:1508697 you're using some sort of "golden image"
creation process: install once, delete unique IDs and other transient
state, then dd the image onto multiple machines and let the boot process
re-populate those unique IDs.

If your image creation process truncated /etc/machine-id to 0 bytes
instead of deleting it altogether, then systemd would be able to do
tricks with bind-mounts to populate it; that's what Debian Live does.
However, I'm not sure how/whether the newly generated ID gets written to
the filesystem when it becomes rw.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508766

Title:
  /etc/machine-id not created if missing

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1508766/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1508697] Re: dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-id

[Simon McVittie]

> Or at least dbus wont (and arguably it shouldn't... seems to me
systemd should be doing this)

I agree with that reasoning. It's fine for D-Bus to be responsible for
creating its own older machine ID file if necessary, but it shouldn't be
responsible for creating the one that belongs to systemd - that's
systemd's job.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1508697

Title:
  dbus-uuidgen --ensure: Symlink instead of copy existing /etc/machine-
  id

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1508697/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

1.10.0 is now available upstream and will reach Debian experimental
shortly. Packaging is in Debian git as usual.

I fixed the two issues that Tyler reported in upstream dbus, and applied
Iain's /run/dbus fix in the Debian packaging.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

 However, even after pulling in that file from the git tree, `make
check` is still failing on the test-bus.sh test.

I think this might actually be a bug in libcap-ng older than 0.7.7:
https://bugs.debian.org/796167. Workaround and more analysis available
on https://bugs.freedesktop.org/show_bug.cgi?id=91684.

** Bug watch added: Debian Bug tracker #796167
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796167

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

As far as I'm concerned, ship it! (Subject to whatever QA is needed
within Ubuntu.) I'm glad the delta has got smaller.

If you badly need 1.10.0 tomorrow, that can happen. It will likely be
functionally identical to 1.9.20, so that should be an easy freeze
exception in any case.

Regarding your changes:

The patch for LP: #1438612 was rejected upstream: Lennart said it's
wrong, and the systemd author's opinion seems relevant here.
Accordingly, I'm not going to take that in Debian or upstream. If it's
necessary in Ubuntu, that's your call.

dbus.user-session.upstart seems way more complicated than it needs to
be, but it's what you have now, so it isn't going to be any worse than
1.8.

User session bits for future reference:

If Upstart is still a first class citizen, and you only need one socket
per XDG_RUNTIME_DIR, I would recommend using
unix:path=$XDG_RUNTIME_DIR/bus like dbus-user-session does under
systemd, instead of doing weird things with abstract sockets. libdbus,
sd-bus and recent (2.45.x) GLib will try that address by default if
DBUS_SESSION_BUS_ADDRESS is not set, although I still recommend setting
it for backwards compat.

If you have a requirement for multiple login sessions (with their own
buses) per XDG_RUNTIME_DIR, you could use the closest possible,
unix:path=$XDG_RUNTIME_DIR/$YOUR_SESSION_ID.bus or
$XDG_RUNTIME_DIR/login-$YOUR_SESSION_ID/bus or something.

In the systemd --user world, I recommend the new dbus-user-session
package as the best way to get a bus per XDG_RUNTIME_DIR. It is
currently useless on non-systemd, but should be harmless there.

I do not plan to support dbus-launch on non-X11, and I hope it can
wither into irrelevance over time. I would like to be able to say that
Wayland and Mir systems will always use XDG_RUNTIME_DIR/bus for their
D-Bus socket.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

Great. As far as I'm concerned, I can ship a 1.10 that is functionally
identical to 1.9.20 any time; for now, I've been holding off on actually
doing that to give the biggest user of D-Bus-with-AppArmor a chance to
try it :-)

I've been avoiding uploading to Debian unstable because the release team
asked people not to (as you said, g++-5 fun), but eventually I'll time
out and upload it anyway.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

I've released 1.9.20, which I'm treating as 1.10 rc1. 1.10 will
hopefully be identical to 1.9.20 except for versioning and NEWS.

 - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet

Done in Debian experimental (1.9.20-1).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1479771] Re: patch to raise service_start_timeout in session.conf does nothing and is unnecessary

[Simon McVittie]

In case it isn't obvious, the patch I mean is debian/patches/81-session
.conf-timeout.patch.

The default service_start_timeout on the session bus was raised to 120s
between dbus 1.0.0 and 1.1.0 (in 2007).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1479771

Title:
  patch to raise service_start_timeout in session.conf does nothing and
  is unnecessary

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1479771/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1479771] [NEW] patch to raise service_start_timeout in session.conf does nothing and is unnecessary

[Simon McVittie]

Public bug reported:

Ubuntu has a long-standing patch claiming to raise the session service
startup timeout from 25s to 60s (with a comment saying it is raised to
40s).

However, this patch is pointless, for two reasons:

* A later directive in the same file which takes precedence, also sets the 
service_start_timeout.
* That later directive sets the service_start_timeout to 120s, so even if the 
patch worked as intended, it would be *reducing* the timeout.

Please consider dropping this.

** Affects: dbus (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1479771

Title:
  patch to raise service_start_timeout in session.conf does nothing and
  is unnecessary

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1479771/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1477086] Re: DBus 1.10

[Simon McVittie]

 - Move dbus-uuidgen unit file patch to using a tmpfiles.d snippet (L
/var/lib/dbus/machine-id - - - - /etc/machine-id) as if we're booting
systemd then we have /etc/mamchine-id

I'll probably do that in the next dbus upload to Debian.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1477086

Title:
  DBus 1.10

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1477086/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1402350] Re: allow writing to systemd journal sockets

[Simon McVittie]

*** This bug is a duplicate of bug 1413232 ***
https://bugs.launchpad.net/bugs/1413232

 Indeed I think we should fix that in /etc/apparmor.d/abstractions/base

AppArmor upstream appear to have made this change in r2850, LP:1413232.

** This bug has been marked a duplicate of bug 1413232
   [systemd] dhclient causes apparmor warnings against 
/run/systemd/journal/dev-log

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1402350

Title:
  allow writing to systemd journal sockets

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1402350/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Simon McVittie from comment #6)
 Unfortunately, systemctl restart dbus (which was never supported either)
 will now start a second dbus-daemon in parallel with the first

I think that's unacceptable.

(In reply to Lennart Poettering from comment #12)
 If at all, use RefuseManualStop=yes on the unit, but I don't like that much
 either.

I don't think this would satisfy the original requirement unless the
ExecStop=/bin/true was also included, and you've said that that's
undesired.

 Please do not apply that ExecStop= thing. You really shouldn't block
that.

Fair enough. NOTOURBUG then.

 The best way is to fix the few services that really need dbus
 unconditionally to be around to add After=dbus.service. And all is good.

OK. In the case of the original bug report, I think this means
wpasupplicant and maybe NetworkManager would have to either turn off
exit-on-disconnect (for libdbus and/or GDBus, depending which they use),
or be After=dbus.service.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1435994] Re: package adwaita-icon-theme-full 3.14.0-2ubuntu7 failed to install/upgrade: trying to overwrite '/usr/share/icons/Adwaita/cursors/arrow', which is also in package gnome-themes-standar

[Simon McVittie]

*** This bug is a duplicate of bug 1417847 ***
https://bugs.launchpad.net/bugs/1417847

** This bug has been marked a duplicate of bug 1417847
   package adwaita-icon-theme-full (not installed) failed to install/upgrade: 
trying to overwrite 
'/usr/share/icons/Adwaita/cursors/81600681408080010102', which is 
also in package gnome-themes-standard-data 3.12.0-1ubuntu1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1435994

Title:
  package adwaita-icon-theme-full 3.14.0-2ubuntu7 failed to
  install/upgrade: trying to overwrite
  '/usr/share/icons/Adwaita/cursors/arrow', which is also in package
  gnome-themes-standard-data 3.12.0-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1435994/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1417847] Re: package adwaita-icon-theme-full (not installed) failed to install/upgrade: trying to overwrite '/usr/share/icons/Adwaita/cursors/00008160000006810000408080010102', which is also in p

[Simon McVittie]

Proposed fix: http://people.collabora.com/~smcv/adwaita-icon-
theme_3.14.0-2ubuntu7co1.diff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1417847

Title:
  package adwaita-icon-theme-full (not installed) failed to
  install/upgrade: trying to overwrite
  '/usr/share/icons/Adwaita/cursors/81600681408080010102',
  which is also in package gnome-themes-standard-data 3.12.0-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1417847/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1417847] Re: package adwaita-icon-theme-full (not installed) failed to install/upgrade: trying to overwrite '/usr/share/icons/Adwaita/cursors/00008160000006810000408080010102', which is also in p

[Simon McVittie]

** Patch added: adwaita-icon-theme_3.14.0-2ubuntu7co1.diff
   
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1417847/+attachment/4365121/+files/adwaita-icon-theme_3.14.0-2ubuntu7co1.diff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1417847

Title:
  package adwaita-icon-theme-full (not installed) failed to
  install/upgrade: trying to overwrite
  '/usr/share/icons/Adwaita/cursors/81600681408080010102',
  which is also in package gnome-themes-standard-data 3.12.0-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1417847/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1431453] Re: package adwaita-icon-theme-full 3.14.0-2ubuntu7 failed to install/upgrade: trying to overwrite '/usr/share/icons/Adwaita/16x16/actions/edit-delete.png', which is also in package adwa

[Simon McVittie]

** Patch added: suggested fix, also covers the other open bug in this package
   
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1431453/+attachment/4365122/+files/adwaita-icon-theme_3.14.0-2ubuntu7co1.diff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1431453

Title:
  package adwaita-icon-theme-full 3.14.0-2ubuntu7 failed to
  install/upgrade: trying to overwrite
  '/usr/share/icons/Adwaita/16x16/actions/edit-delete.png', which is
  also in package adwaita-icon-theme 3.14.0-2ubuntu7

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/adwaita-icon-theme/+bug/1431453/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Michael Biebl from comment #1)
 We might have a problem, if /usr is on NFS and (at least on Debian)
 dbus-daemon being installed in /usr/bin, which would keep the FS busy.

If dbus-daemon really badly needs to be moved to the rootfs, then it can
be... but in Debian, some libraries need to move first before that
becomes useful (libcap-ng0, libapparmor1).

If this is something we support upstream then I'd like to do it by
introducing a ${rootbindir} like systemd has, rather than moving
binaries around and patching systemd units etc. to compensate for it
like Ubuntu has traditionally done. But I would prefer not to have to
support it tbh.

(Also, is there any reason to prefer NFS /usr that doesn't apply equally
to preferring NFS rootfs?)

(In reply to Martin Pitt from comment #0)
 So what we really need is some way to say Don't stop dbus.service before
 any D-Bus client (i. e. *.service of Type=dbus). We could make dbus.service
 start before basic.target and stop after basic.target and add
 DefaultDependencies=no, so that it stops after most stuff; or change the
 implied After=dbus.socket in systemd to After=dbus.service. But that would
 also be prone to causing cyclic dependencies, if you e. g. have /var on NFS
 and need it to start dbus. (I didn't test that, it's just a gut feeling as
 remote file systems that you need to boot are notoriously susceptible to
 dependency loops.)

The fewer constraints we have to apply to startup, the better, to make
it more likely that dependency loops can be avoided in arbitrarily weird
situations (NFS /usr and/or /var, or networking infrastructure that
needs D-Bus - you can have one or the other but you cannot have both).
So I would be OK with giving dbus.service DefaultDependencies=no, but I
would not necessarily encourage requiring it to start before
basic.target.

If we give it DefaultDependencies=no and RequiresMountsFor=/usr /var
/proc, but do not order it either before or after basic.target, would
that help? Then we'd get:

startup: /usr and /var must be mounted before the system dbus-daemon
starts

shutdown: dbus-daemon must stop before /usr and /var are unmounted

Would not having the implicit Conflicts on shutdown.target mean that
dbus-daemon would survive the initial shutdown transaction and only be
killed when systemd got as far as unmounting the filesystems, or does it
schedule everything required for shutdown, including the unmounting, as
a single large transaction?

(In reply to Michael Biebl from comment #1)
 systemd has a final killing spree, before it unmounts the file systems and I
 don't think dbus needs to do something special on stop?

It does not need to do anything special on stop. Is this killing spree
suffiently early that it happens before attempting to unmount /usr?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Martin Pitt from comment #8)
 I don't see anything explicit
 which would declare cannot restart; I haven't tested this (travelling/no
 real computer), but would something like 
 
 ConditionPathExists=!/run/dbus/system_bus_socket
 
 prevent further starts/restarts?

Good idea, I'll try it. systemd guarantees that /run is a tmpfs, so the
what if I have stale misc lying around in /var/run? question that we
would have had under sysvinit and possibly Upstart does not exist.

 BTW, this is being discussed on the upstream ML too:
 
 http://lists.freedesktop.org/archives/systemd-devel/2015-April/030070.html

I am aware, and have replied there.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

Created attachment 114829
system bus: do not allow stopping the system dbus-daemon

There is nothing that prevents D-Bus from stopping very early,
way earlier than all of the Type=dbus services. There is an
attempt to prevent that as systemd implies After=dbus.socket
for Type=dbus units, but that doesn't save us: you can't re-start
D-Bus after shutting it down and expect things to just work, as
it loses all of its state.

Putting dbus.service Before basic.target was considered and rejected,
because it's a recipe for cyclic dependencies: as soon as
dbus.service wants to be After anything that is After basic.target
(e.g. NIS and other user databases, or remote filesystems) you
get a cycle. dbus-daemon does not need to start early, it only
needs to stop late.

systemd has a final killing spree before it unmounts the
file systems, which should be sufficient to avoid dbus-daemon
preventing a separate /usr from being unmounted; this does not
consider KillMode. dbus-daemon doesn't need to do anything special
during shutdown, so it's OK that it survives until then.

Based on a suggestion from Michael Biebl and Martin Pitt.

---

How's this? I made the stop command be echo instead of true so that
it leaves a hint in systemctl status if someone tries to stop it by
hand.

Unfortunately, systemctl restart dbus (which was never supported
either) will now start a second dbus-daemon in parallel with the first,
and in my testing, the second one will get all new connections. Any
ideas for how to avoid that? Perhaps it would be better to make the stop
command exit nonzero? ... but then we'd log scary messages during a
normal shutdown, which is no better really.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Simon McVittie from comment #6)
 Perhaps it would be better to make the stop command exit
 nonzero?

Straw man:

ExecStop=/bin/sh -c echo Stopping the system dbus-daemon is not
supported. Reboot the system instead.; exit 1

... which does work, but logs Unit dbus.service entered failed state
during shutdown. It seems better to avoid crying wolf if possible,
because it can hide real issues.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Martin Pitt from comment #8)
 ConditionPathExists=!/run/dbus/system_bus_socket

That can't be suitable, because dbus.socket creates that filesystem
object, so dbus-daemon would never start.

Removing --nopidfile and adding ConditionPathExists=!/run/dbus/pid in
addition to the patch I posted above (for upstream consumption that
would be @DBUS_SYSTEM_PID_FILE@) does work.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1438612]

[Simon McVittie]

(In reply to Martin Pitt from comment #4)
 I'm not sure if root on NFS was ever attempted/supported. You'd basically
 need half an OS in your initramfs then? :-)

Yes it is/was, with or without an initramfs:

https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt
https://anonscm.debian.org/cgit/kernel/initramfs-tools.git/tree/scripts/nfs

  The fewer constraints we have to apply to startup, the better [...]
  So I would
  be OK with giving dbus.service DefaultDependencies=no, but I would not
  necessarily encourage requiring it to start before basic.target.
 
 Why not before basic.target? This would make it a basic system service which
 everyone could rely on. It's already kind of that through dbus.socket? It
 could lead to a more serialized boot of course, as non-dbus services would
 have to wait for dbus.service then.

If dbus.service *on a particular system configuration* is After
something that is After basic.target, and basic.target is After
dbus.service, then we have a cyclic dependency on that system
configuration. (This is regardless of whether it works without cyclic
dependencies for the relevant distribution's dbus maintainers, who
presumably know enough to avoid bizarre boot orderings.)

Notable examples of things that dbus might need:

* NIS and other sources of users
* networking and other non-trivial infrastructure to get /usr

Debian and Ubuntu have traditionally run dbus as a rc2.d service, so
there is nothing to stop it having such dependencies.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1438612

Title:
  remote file systems hang on shutdown, D-BUS stops too early

To manage notifications about this bug go to:
https://bugs.launchpad.net/dbus/+bug/1438612/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #91)
 Realization of the first three points would require adding a new interface
 to gabble. I imagine it as an extension of connection interface providing
 settings individually for every account. Would using gdbus codegen just
 like in case of the currently implemented otr channel be acceptable here?

You could make it go next to the Connection just like Xavier's code
produces an object next to the Channel, yes.

(Unfortunately, the fact that, in general, telepathy-glib uses the
deprecated dbus-glib instead of GDBus is not going to get fixed, unless
someone with a lot more time available than me picks it up. See the
various Telepathy 1.0 bugs for details.)

 I
 suppose that adding these features would mean some major changes in the
 current implementation which is completely closed in the channel interface.

Making behind-the-scenes C function calls between the Connection and
Channel objects is fine.

 There are also things that need to be fixed as stated above:
 ...
 I understand that they have to be done first before introducing new changes?

Yes, I think that would be better than hoping they will be fixed later.

I consider those fixes to be merge blockers for these branches, because
I don't want to add an interop and security feature that, on closer
inspection, turns out to be non-interoperable or insecure :-)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1348393] Re: OpenAL 1.15.x Breaks Multiarch (makes 32-bit wine uninstallable on 64-bit system)

[Simon McVittie]

** Bug watch added: Debian Bug tracker #756066
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756066

** Also affects: openal-soft (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756066
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348393

Title:
  OpenAL 1.15.x Breaks Multiarch (makes 32-bit wine uninstallable on
  64-bit system)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openal-soft/+bug/1348393/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #87)
 Why is the patch protocol-specific? 

Telepathy does not have any central point where OTR can be done for all
protocols and all UIs simultaneously. We can either do it once per
protocol backend, or once per UI. Once per UI would break the ability to
log OTR messages or have them appear correctly in more than one UI (e.g.
both Empathy and GNOME Shell). Every attempt at implementing OTR in
Telepathy has had the plan to do it once per protocol backend; this
implementation is no different. In practice, like most new features,
everyone prototyped it in the XMPP protocol backend first, because
that's the one that works best.

I think the approach that is most likely to yield results in a finite
time is to get the XMPP implementation high-quality and mergeable first,
then expand to the other protocols; then any implementation mistakes in
the first implementation will hopefully not be repeated, and the rest
will be a simple matter of pretty much what Gabble did. Using a
library for common code, or adding functionality to libotr, would be
fine too, but that's an implementation detail.

Anyone interested in this could add similar glue to telepathy-haze to
cover the various proprietary protocols (AOL, etc.). It might have
seemed more natural to go for -haze first, but -haze uses libpurple,
which is not really designed for things that aren't shaped like Pidgin,
so it can be awkward to get right and doesn't make a great place for
prototyping. The missing protocol backends after that would be
telepathy-salut for link-local XMPP, telepathy-idle for IRC, and
telepathy-rakia for SIP. I think it'd make sense to do -haze and maybe
-salut. I'm not sure -idle or -rakia is necessarily worthwhile, but if
people do use OTR on those protocols in practice, sure, why not.

(In reply to comment #87)
 Would it be possible to use the same code for the new gnome-chat application
 which will likely replace Empathy?

The majority of the glue between Telepathy and libotr (as exemplified
here by patches to Gabble), and the design: yes, it lives in the
protocol backend(s).

The UI: no, the UI code in Empathy is specific to Empathy. gnome-chat
would need to provide a way to enable/disable OTR and mark fingerprints
as trusted, and to be properly secure, it would need to display the
notifications from libotr in a way that cannot be spoofed by contacts.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #76)
 1) handle html, I'm not sure to understand what you mean or why it is that
 important... Maybe you can make the changes that you want?

Looking into it. The more important direction (don't send plain text
where HTML is expected, so that parts of messages that happen to look a
bit like html tags aren't silently ignored) is easy, it just needs
g_markup_escape_text().

The other direction (don't send HTML where plain text is expected) is
more difficult, but libxml should be able to do it; and if we don't, the
failure mode is that a user sees HTML markup instead of plain text,
which isn't *so* bad.

 2) Find a solution if we don't want the other end to be able to initiate an
 OTR session without approving it first.

I think a CM parameter is the only way to do this. It'll work for MC-
stored accounts (which includes all Haze accounts and all unbranded
accounts like generic Jabber/IRC, even if GOA is used), and for UOA-
stored accounts.

I agree that GOA's account parameter storage limitations mean it won't
work for GOA-stored Google Talk or Facebook accounts, or GOA-stored
Windows Live accounts in the unlikely event that Microsoft bring back
their XMPP bridge. If you want communications privacy, Google and
Facebook are probably not the ideal option anyway... and that GOA issue
is not something that Telepathy can fix in any case.

 3) Fix string spelling. Maybe you can patch them yourself, as I'm not
 native? :)

Sure.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #58)
 + type=(say) access=read
 
 Are these literally the hex and binary versions of the same digest, or do
 they have different information content? (Or is the string version some
 OTR-specific thing that is easier to transcribe than hex?)

I'm not particularly happy about this type duplicating the information:
whenever there's duplication, there's the possibility that the
duplicates don't agree. I can see why you did it, though - the OTR
library doesn't seem to have a function to convert a human-readable
digest back into binary (although we could easily write one), so you
currently need the binary digest in order to set trust.

If possible I'd prefer to stick to one encoding or the other,
consistently - either always a string (which I think is what I'd
prefer), or always a byte-array. At the moment we only put the string
form in message headers, not the byte-array.

I'm tempted to implement a function to turn the string into binary
(decode hex, ignore whitespace, report an error unless it has exactly 40
hex digits) and just use strings throughout.

 I think it would also be useful to spec that one of the forms of the remote
 fingerprint will appear in the message header (0'th part) of each individual
 message, perhaps { otr-remote-fingerprint: a string }. That would make it
 easy for someone to do either of these things in a race-condition-free way:
 
 * record in the Logger that the messages were encrypted/verified
 * give the Logger a configuration setting [ ] do not log OTR messages
   (which it would recognize by seeing that they have an OTR remote
 fingerprint

You added otr-sender-fingerprint to received messages. I think we should
also add a fingerprint to messages that were sent during an OTR session,
so that we can associate the logged session with the fingerprint (or
avoid logging them at all), too.

For now I'm changing it to otr-remote-fingerprint, because that's always
the easier one to get - we could use otr-sender-fingerprint and otr-
recipient-fingerprint if there's some reason that's better, but just
having one seems easier.

(In reply to comment #50)
 Could we also get a config option that turns this whole feature on/off?

Still needed, IMO.

(In reply to comment #61)
 I would really like im-channel to implement o.fd.Telepathy.Securable

Non-blocker but still desirable. Given what I said in Comment #78, I
think we can set Encrypted when OTR is active, but we can't set Verified
in any case, because the thing that Securable says we Verified (that the
key with which we're encrypting belongs to the contact identified by the
Channel's Target_ID) does not seem to be what OTR actually verifies.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

Security issue: it isn't at all clear to me what trust means here. In
something like GPG or SSL, the trusted assertion is the key whose
fingerprint is ...63c7cc90 is controlled by 'Simon McVittie
simon.mcvit...@collabora.co.uk' or the key whose fingerprint is ...
is controlled by the administrators of bugs.freedesktop.org - it binds
a key to a somewhat human-comprehensible identity (name and email
address, or domain name). I would have automatically assumed that the
same was true in OTR - binding a key fingerprint to a JID (or whatever
else the identifier is, in non-XMPP protocols) - but that doesn't seem
to be happening here. Instead, we're saying I trust this fingerprint
but it isn't clear what property of the fingerprint we're trusting. In
particular, we don't seem to be binding a fingerprint to a JID.

Concretely, suppose I talk to xavier.claess...@collabora.co.uk and you
present key ID 12345678 [1]. I verify out-of-band that that is really
your key ID (perhaps by phoning you or receiving GPG-signed email) and
mark it as trusted. Next, I talk to guillaume.desmot...@collabora.co.uk
who presents key ID fedcba98, and again, I mark it as trusted. Now
Guillaume hijacks your XMPP account, and when I next try to talk to you,
Guillaume presents key ID fedcba98. I have trusted that key, so my UI
doesn't indicate that anything is wrong - but it isn't your key, it's
Guillaume's!

How does OTR typically deal with this situation? Do OTR users memorize
key IDs and ignore the JIDs and contact names presented by the UI, or
does the Pidgin OTR plugin store pairs (JID, key ID) and warn the user
if an unexpected pairing is found, or does trust here mean I trust
this person not to impersonate any of my other contacts?

[1] in real life the key ID would be longer than that, but you get the
idea

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #78)
 In particular, we don't seem to
 be binding a fingerprint to a JID.

On closer inspection of libotr, it seems we are indeed binding a (remote
username, local account name, protocol) tuple to a fingerprint; the API
just doesn't make that obvious.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

  fp_data = g_variant_get_data (fp_variant);
  fp = otrl_context_find_fingerprint (context, (guchar *) fp_data, 0, NULL);

I'm still considering use string fingerprints with error-checking to
be a merge blocker, because I don't think this code is OK for the case
where fp_data has length != 20 bytes. I think
TrustFingerprint(DEADBEEF) should raise InvalidArgument, whereas
TrustFingerprint(12345678 12345678 12345678123456781234578) (with any
whitespace) should work.

If you strongly prefer the binary encoding, I'd be OK with making
TrustFingerprint([a number of bytes other than 20]) an InvalidArgument,
but I think string fingerprints are going to be nicer to deal with.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

I've made most of the changes I wanted but haven't had time to test them
yet. Use at own risk:

http://cgit.freedesktop.org/~smcv/telepathy-gabble/log/?h=untested-otr

Still to do:

* testing (in particular, send lt; and a message that resembles HTML
  in both directions between Empathy and Pidgin, and check that neither is
  misinterpreted)

* review from someone who understands libotr

* Empathy: make sure OTR notifications are presented in a way that
  peers cannot fake. Because Empathy doesn't support HTML messages yet,
  distinctive formatting would be enough.

* string-only handling of fingerprints (emit strings to D-Bus,
  parse hex - binary when asked to trust a fingerprint from D-Bus)

Nice to have, but not blockers:

* TPAW UI for the enable-otr boolean parameter (for now, early adopters
  can turn it on with mc-tool - but I think real UI *is* a blocker for
  switching the default to be enabled)

* Chan.I.Securable.{Encrypted,Verified} integration

* enable-opportunistic-otr boolean parameter, and UI for the same
  (it will end up looking very similar to enable-otr, but with different
  handling in im-channel*.c)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

Implementation in Gabble:

+ /* FIXME: There should be no sender for a notification, but setting handle to
+ * 0 makes empathy crash atm. */
+ tp_message_mixin_take_received (G_OBJECT (self),
+ tp_cm_message_new_text (base_conn,
+ tp_base_channel_get_target_handle (base_chan),
+ TP_CHANNEL_TEXT_MESSAGE_TYPE_NOTICE, text));

Is this a message from the OTR library, something like *** Verified
peer fingerprint: b...@example.com ***?

I think using the target handle for this is OK semantically.

However, I suspect remote users can spoof this by sending their own
NOTICE. Messages coming from the OTR library should have a distinctive
message header that an OTR-literate UI can take as evidence that they
were locally-generated.

Ideally, that distinctive message header should be a machine-readable
version of the message, so OTR-literate UIs (Empathy) can discard the
untranslated version from Gabble and display something translated. We've
always had a policy of putting UI strings and their translations in the
UIs, not the CMs.

+ return g_variant_new ((s@ay), display_fp,
+ g_variant_new_fixed_array (G_VARIANT_TYPE_BYTE, fp_raw, 20,
...
+ guchar our_fp_raw[20];

The magic number 20 makes me nervous. Isn't there a constant for length
of a raw OTR fingerprint in bytes in libotr?

If there really isn't, #define'ing our own would be better than nothing.

+static void
+otr_inject_message (void *opdata,
+ const gchar *accountname,
+ const gchar *protocol,
+ const gchar *recipient,
+ const gchar *message)
+{
+ inject_message (opdata, message);
+}

Is @message text/plain or text/html? Telepathy can only do text/plain at
the moment, so if it's text/html, we need to strip tags, then unescape
entities (stuff;).

+static gint
+otr_max_message_size (void *opdata,
+ ConnContext *context)
+{
+ return 0;
+}

We should probably give some guess at what's generally interoperable.

+ msg = otrl_proto_default_query_msg (get_self_id (self),
OTRL_POLICY_DEFAULT);

Do we need to update what otr_policy() would return here, too?

+ bus_name = g_strconcat (tp_base_connection_get_bus_name (base_conn),
+ .OTR, NULL);

I suppose this isn't *so* bad, but the spec should tell the API user
where to find this name.

+ content = wocky_node_get_content_from_child (node, body);
+
+ err = otrl_message_sending (userstate, ui_ops_p, self,
+ get_self_id (self), xmpp, get_target_id (self),
+ priv-instag, content, NULL, new_content,
+ OTRL_FRAGMENT_SEND_ALL_BUT_LAST, NULL,
+ NULL, NULL);

Does otrl_message_sending() expect @content to be text/plain or
text/html? If it expects text/html, we need to escape special characters
with g_markup_escape_text().

Similarly, is @new_content text/plain or text/html? If text/html, we
need to strip tags and unescape entities.

+gchar *
+gabble_im_channel_otr_receiving (GabbleIMChannel *self,
+ const gchar *content)

Same here.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

Just doing the spec right now:

 The extra DBus channel interface is implemented using GDBus
 so it needs to be exported on a different bus name.

Ugh. Can we not do strange hacks like this, please? Either use the
extensions mechanism, or save it for 1.0.

+ interface name=im.telepathy.v1.Channel.Interface.OTR1
+ tp:causes-havoc=experimental
+ tp:added version=Gabble 0.UNRELEASED(Gabble-specific)/tp:added

If doing this in 0.x, please use o.fd.Channel.Interface.OTR1 and add it
to telepathy-spec (OK to go via extensions/ until we do the spec - tp-
glib dance, though).

In 1.0, certainly add it to the spec.

+ A simple D-Bus API a
+ href=https://otr.cypherpunks.ca/;Off The Record/a.

... API for a...

+ pThe current trust level of this channel:
+ 0=TRUST_NOT_PRIVATE, 1=TRUST_UNVERIFIED, 2=TRUST_PRIVATE,
+ 3=TRUST_FINISHED/p

This deserves a tp:enum and documentation.

I assume the meanings go something like this:

TRUST_NOT_PRIVATE: not using OTR at all? (Can we also see this when using OTR 
but something has gone wrong?)
(o.fd.Channel.I.Securable.Encrypted=FALSE, 
o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_UNVERIFIED: the channel is encrypted, but you might be talking to
a man-in-the-middle instead of the peer you expected.
(o.fd.Channel.I.Securable.Encrypted=TRUE,
o.fd.Channel.I.Securable.Verified=FALSE)

TRUST_PRIVATE: the channel is encrypted, and the user has indicated that the 
peer's key fingerprint is trusted to belong to that peer.
(o.fd.Channel.I.Securable.Encrypted=TRUE, 
o.fd.Channel.I.Securable.Verified=TRUE)

TRUST_FINISHED: this channel is over, nothing more should be sent or received 
on it.
(o.fd.Channel.I.Securable.Encrypted and o.fd.Channel.I.Securable.Verified keep 
their previous values?)

What are the possible state transitions? I assume can only increase?

+ type=(say) access=read
+ pUser's current fingerprint. The first element is a human readable
+ fingerprint that can be displayed to the user so he can communicate it
+ to the other end by other means so he can trust it. The 2nd element is
+ the fingerprint raw data./p

Are these literally the hex and binary versions of the same digest, or
do they have different information content? (Or is the string version
some OTR-specific thing that is easier to transcribe than hex?)

+ property name=RemoteFingerprint
+ tp:name-for-bindings=Fingerprint
+ type=(say) access=read
+ tp:docstring xmlns=http://www.w3.org/1999/xhtml;

What value does this take when the channel is not using OTR? ('', [])?

When we're in the UNVERIFIED state, am I right in thinking that we are
cryptographically guaranteed to have the right fingerprint for who we're
talking to, but the thing that is unverified is that the fingerprint
belongs to the person we wanted to talk to? (i.e. if we're talking to a
man-in-the-middle, this would be the fingerprint of the man-in-the-
middle's key, right?)

Is it possible for this to change? (Presumably from ('', []) to non-
empty, at the same time that the trust changes to UNVERIFIED or
PRIVATE?)

After this has become non-empty, can it change further? (I would hope
not.)

I think it would also be useful to spec that one of the forms of the
remote fingerprint will appear in the message header (0'th part) of each
individual message, perhaps { otr-remote-fingerprint: a string }. That
would make it easy for someone to do either of these things in a race-
condition-free way:

* record in the Logger that the messages were encrypted/verified
* give the Logger a configuration setting [ ] do not log OTR messages
  (which it would recognize by seeing that they have an OTR remote fingerprint

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #50)
 Could we also get a config option that turns this whole feature on/off? I
 ask because some industries (like the one where I work) require that all
 electronic communications related to the business get recorded and reviewed
 by compliance officers and made available to regulatory agencies upon
 request.

I think we do need a connection parameter to control this. I think the
possible sensible settings are:

- never use OTR, behave exactly as though it was not implemented

- start an OTR conversation if the local user or remote peer explicitly
requests it

- try to start OTR conversations automatically

I think that would be most comprehensible as two booleans: something
like enable-otr (default false initially, default true after a couple
of releases) and enable-opportunistic-otr (not implemented in Xavier's
patch, but someone could add it).

The writer of Comment #50 would explicitly set enable-otr to false; the
people getting excited about this bug would explicitly set enable-otr to
true, and when implemented, probably also set enable-opportunistic-otr
to true.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

Corner cases:

What happens when we try to send a message and the channel is already
TRUST_FINISHED? I think we should refuse, for the rest of the lifetime
of that channel (until Close()), to avoid the security flaw where we
send messages to a channel that just closed.

What happens when we close a channel locally? I think the answer should
be we terminate the OTR session, and start from an unsecured state next
time - even if the channel is in fact going to respawn due to
unacknowledged messages. This means the channel needs to reset its
Encrypted flag, Verified flag and all OTR state when it respawns. We
will still be able to tell the rescued messages were encrypted/verified
because the header that I suggested adding will say so.

What happens if I'm talking to b...@example.com/Laptop using OTR, and I
receive a message from b...@example.com/Phone without OTR? I hope the
answer is libotr deals with it and reports
OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED. Is it safe (as in, not a security
vulnerability) to rely on that?

What happens when we receive a message and the channel is already
TRUST_FINISHED? I hope the answer is libotr deals with it and reports
OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED. Is it safe (as in, not a security
vulnerability) to rely on that?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

I would really like im-channel to implement o.fd.Telepathy.Securable -
as a starting point we can have the two booleans not be requestable, and
just have them set by the OTR code calling a new
gabble_im_channel_indicate_security
(GABBLE_SECURABLE_ENCRYPTED|GABBLE_SECURABLE_VERIFIED) (or only one of
those, or neither of those, as appropriate).

I notice we never specified how those properties did change
notification, because our only use of them so far was for SASL channels.
Let's retcon them to they emit PropertiesChanged in the 0.x and 1.0
spec.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #59)
 Ideally, that distinctive message header should be a machine-readable
 version of the message, so OTR-literate UIs (Empathy) can discard the
 untranslated version from Gabble and display something translated. We've
 always had a policy of putting UI strings and their translations in the UIs,
 not the CMs.

The more I think about this, the more I think Gabble should not contain
translated strings. It's OK for it to contain strings in the C locale
(international English), but all translation should be taking place
somewhere that already needs to be translated - the UIs.

As a purely practical thing, Gabble does not have any of the translation
machinery, so those strings aren't going to be translated anyway.

Is the OtrlMessageEvent enum sufficiently stable that we can use it in
the D-Bus API directly? That would probably be the easiest way. The only
other information we need to put in the message header is:

- for OTRL_MSGEVENT_SETUP_ERROR: gcry_strerror (err)
  (perhaps { otr-error: that string })

- for various codes: the username or account name, which the UI already
  knows anyway

- for OTRL_MSGEVENT_RCVDMSG_UNENCRYPTED: the unencrypted message
  (perhaps { otr-unencrypted-message: that string })

- for OTRL_MSGEVENT_RCVDMSG_GENERAL_ERR: the message
  (perhaps { otr-error: that string })

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

After fixing the obvious things, it would also be good to get someone
who understands the OTR protocol and/or libotr to review this
(particularly the things I raised in Comment #59 and Comment #62). I
don't think there's any such person among the main Telepathy developers,
but perhaps one of the 49 people in Cc can give an informed review?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

+static void
+otr_handle_smp_event (void *opdata,
+ OtrlSMPEvent smp_event,
+ ConnContext *context,
+ unsigned short progress_percent,
+ gchar *question)
+{
+ DEBUG (UNIMPLEMENTED\n);
+}

Is this OK/allowed? Should we at least tell libotr no, I don't
implement SMP?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

en_GB speaker review of strings:

+ notify (self, _(An error occurred when encrypting your message and 
+ not sent.));

This sentence no verb.

Maybe ... and it was not sent?

+ notify (self, _(Your message was not sent because %s closed their 
+ connection. Either close your private connection, or refresh it.),
+ context-username);

What does that last sentence mean in Telepathy terms? If it means you
should close this channel (i.e. close the Empathy window), perhaps
Close this conversation and try again? (Or perhaps we should even
auto-close the channel, but we're trying to get away from self-closing
channels.)

+ err_msg = g_strdup (_(You transmitted an unreadable encrypted
message.));

Thought bubble: no, I'm pretty sure I didn't :-) If this happens, it's
presumably either Gabble's fault, or one of the user's other resources,
not anything the user themselves typed.

Internal error: transmitted an unreadable... instead, maybe?

Same for You transmitted a malformed data message..

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

A brief glance at Empathy:

+ return _(The conversation is currently encrypted with 
+ OTR but the remote contact has not been 
+ authentified);

There is no such word. I think you mean authenticated and/or
identified.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #69)
 It can be done later. ATM the policy is MANUAL and it's the right thing
 until we have an explicit option. I would consider this non-blocker future
 enhancement.

That's OK, but only if MANUAL specifically means do not initiate *or
accept* OTR sessions without user input.

(In reply to comment #70)
 I would consider this non-blocker future enhancement. Atm I'm not proposing
 the spec to be included in tp-spec, only private to gabbleempathy.

I don't like private APIs. They have a nasty habit of becoming de facto
public APIs as soon as you commit them (and we only recently managed to
get rid of Renaming being a private API, despite it not having changed
for 5 years).

We have API versioning now, so if it's good enough to merge, it's good
enough for the spec.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 296867]

[Simon McVittie]

(In reply to comment #68)
 I can change the iface name but it doesn't matter much. I would like to
 avoid extensions/ nightmare though, I don't want to write code using that in
 master and port it again in next.

OK. I still would prefer to use o.fd.T for the 0.x version though.

  This deserves a tp:enum and documentation.
 
 I didn't write it because gdbus-codegen does not use it.

Makes sense, but the documentation value is worth it.

 I *think* (need to double check) that in that case you'll still be sending
 encrypted messages but the other side won't be able to decrypt them and will
 display a message The encrypted message received from %s is unreadable, as
 you are not currently communicating privately..

It would make sense to get an OTR expert to confirm that how we're
handling this is secure.

  What are the possible state transitions? I assume can only increase?
 
 I think it can only increase unless the local user did something. Like it
 can go from PRIVATE to UNVERIFIED if user types /otr untrust.

Ah, that's a good point. Please document that transition (although it
can only happen because the user did something odd - but that odd thing
might make sense as an undo mechanism).

I suppose this means that Securable.Verified can turn off as a result of
an undo button, too...

 It currently
 cannot go back to NOT_PRIVATE because I don't support ending the otr
 session, but could add a /otr end for that. pidgin can do that.

Please don't. In Pidgin, maybe that feature is OK, because typically
only one UI handles a window (Pidgin's D-Bus API aside). In Telepathy,
where more than one UI can be interested in a channel, that feature
would be an unlikely security flaw: if I type the secret password is
weasel and for some reason another process turns off OTR just as I hit
Enter, that's Bad™.

If the remote peer can turn off OTR, then that elevates that situation
to a remotely exploitable security flaw, but AIUI the design of OTR
doesn't allow that to happen.

 It is the same information, the string is utf8 (ascii even) to display, the
 ay is hex form (20 bytes, not utf8).

All hex is UTF-8, because hex is a subset of ASCII, and ASCII is a
subset of UTF-8... or do you mean binary?

If the machine-readable fingerprint is like adc83b19e793491b1c6e (20
hex digits encoding 80 bits of entropy) that should be a string. If it's
like \xad\xc8... (20 bytes encoding 160 bits of entropy, most likely a
SHA-1) that should indeed be an 'ay'.

As for the human-readable version, do I infer correctly that it is not
just hex, but instead an OTR-specific encoding that is easier to
transcribe or more dense or something?

 I think if the other end stops the OTR session then trustlevel goes to
 FINISHED but you'll still be sending encrypted messages and the other side
 (pidgin-otr) will say I received an encrypted messages, have no idea what
 it contains. Need to try that scenario to check.

My understanding is that OTR publishes the temporary key at the end in
order to provide deniability (although when I looked at the security
properties of OTR and XTLS a few years ago I couldn't work out what
extra deniability this actually provides...) and so continuing to
encrypt messages with it would be Very Bad? But I could be wrong

 Could be useful, atm the logger still record the conversation. It's a good
 idea to add that in the message parts. Do you consider that merge blocker?
 probably users expects their OTR messages to not be stored on disk. otoh if
 they really care about security and they don't have encrypted HDD I don't
 know what they are thinking about...

I would say putting in the header is a merge blocker, but implementing
the preference in the Logger is not.

  I think using the target handle for this is OK semantically.
 
 yeah, probably, but it could be local-error messages, not something sent by
 the remote end.

Hmm. Maybe it should be the self-handle... but we implement delivery
reports as messages claiming to be from the peer, and this is fairly
similar.

 You're right, yes. I guess the best is to have a signal on the OTR iface to
 transmit the OtrlMessageEvent enum.

I'd put it in the message header - less OTR-specific API, better
graceful degradation for non-OTR-literate clients.

 About translation, there is messages from otr_error_message() as well. Those
 are sent to the other end on error. We should probably not translate them at
 all, I don't want you to receive French messages from me. English is the
 international language, I guess. In a perfect world we could remember the
 language of each contact...

Oh, I hadn't realised otr_error_message() goes to the peer. I think that
deserves a comment.

Yes, if we can't do decent l10n, we should say it's the C locale
(international English).

 pidgin-otr says 0 for xmpp as well. OTR encryption can expand a bit the size
 of messages, but that's not new that user sending huge text could not be
 interoperable. I don't think gabble tries to prevent it anywhere.

[Bug 296867]

[Simon McVittie]

(In reply to comment #68)
 It doesn't matter, if the message is in the form ?OTR:base64 then it
 puts new_content to whatever the original message was (html or not). OTR
 doesn't change anything if user wants to send html message as plaintext,
 empathy will escape when displaying them.

Are you saying that in this message

message
  body?OTR:123123123/body
/message

the recipient is expected to decrypt 123123123 and treat the result as
plain text, but in this message

message
  html xmlns='http://jabber.org/protocol/xhtml-im'
body xmlns='http://www.w3.org/1999/xhtml'
  ?OTR:456456456
/body
  /html

the recipient is expected to decrypt 456456456 and treat the result as
HTML? Or what?

There must be a rule you can use to determine whether the decrypted
content is text/plain or text/html. Text that may contain HTML is not
a well-formed concept - either the message lt; is a 4 character reply
to remind me how you escape  in HTML?, or it's a single U+003C LESS-
THAN SIGN character. It can't be both.

It is entirely possible that the rule is do whatever Pidgin does,
which in practice probably means it's always treated as HTML - that's
what my review comments assume.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs