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

> 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

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

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

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

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

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

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

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

*** 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

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

*** 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

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

*** 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

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

** 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

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

*** 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

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

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

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

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

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

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,

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

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:

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

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

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

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

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

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.

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

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,

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

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,

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

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

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

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

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

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

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

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

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

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 1801814] Re: Environment overwrites XDG_DATA_DIRS

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

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

** 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

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

** 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 =>

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

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),

[Bug 336634]

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:

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

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

[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.

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

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

** 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

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

** 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

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

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

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

> 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

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

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

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

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,

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

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

[Bug 1709164] Re: [MIR] bubblewrap

> 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

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

> 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

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

> 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

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

> 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 --->

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

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

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

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

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

** 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

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

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

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

... 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

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

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:

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

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

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

> 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 proj

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

> 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

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

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

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

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

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

> 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

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

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

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

> 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

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

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

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

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

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

> 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

[Bug 1477086] Re: DBus 1.10

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

[Bug 1477086] Re: DBus 1.10

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

[Bug 1477086] Re: DBus 1.10

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

[Bug 1477086] Re: DBus 1.10

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

[Bug 1477086] Re: DBus 1.10

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

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

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

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

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

[Bug 1477086] Re: DBus 1.10

- 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

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

*** 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

[Bug 1438612]

(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

[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

*** 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

[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

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

[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

** 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

[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

** 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

[Bug 1438612]

(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

[Bug 1438612]

(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

[Bug 1438612]

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

[Bug 1438612]

(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

[Bug 1438612]

(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

[Bug 1438612]

(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

[Bug 296867]

(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

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

** 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

[Bug 296867]

(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

[Bug 296867]

(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

[Bug 296867]

(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

[Bug 296867]

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

[Bug 296867]

(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 296867]

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

[Bug 296867]

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

[Bug 296867]

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), +

[Bug 296867]

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

[Bug 296867]

(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

[Bug 296867]

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

[Bug 296867]

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

[Bug 296867]

(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

[Bug 296867]

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

[Bug 296867]

+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

[Bug 296867]

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,

[Bug 296867]

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

[Bug 296867]

(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

[Bug 296867]

(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

[Bug 296867]

(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

  1   2   >