*** 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 no
This was fixed in 0.4.1-3 (2021).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to bubblewrap in Ubuntu.
https://bugs.launchpad.net/bugs/1798967
Title:
bubblewrap has wrong description after setuid bit was removed
Status in bubblewrap
> [flatpak search meld] produces 3,010 spurious identical error messages
That's https://github.com/ximion/appstream/issues/384, which is a
libappstream bug that cannot be fixed by a Flatpak change (as much as we
might like to). I contributed a fix which was included in appstream
0.15.3, so this SR
Is this going to happen in 23.10? It seems to have been stalled in
-proposed since May.
After the imminent Debian 12 release (which includes polkit 122), I
intend to start removing legacy polkit 0.105 support, with my goal being
polkitd-pkla no longer existing in Debian 13, and packages no longer
** Also affects: flatpak (Ubuntu)
Importance: Undecided
Status: New
** Package changed: flatpak (Ubuntu) => flatpak
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to appstream in Ubuntu.
https://bugs.launchpad.net/bugs/2006110
T
As of version 121+compat0.1-1, the relationship between packages has
changed to this:
* polkitd always requires polkitd-javascript and duktape, and always
interprets JavaScript policies
* polkitd-pkla is now an optional addon (the upstream polkit-pkla-compat
project, as shipped in e.g. Fedora) wh
More discussion here: https://salsa.debian.org/utopia-
team/polkit/-/merge_requests/6
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to policykit-1 in Ubuntu.
https://bugs.launchpad.net/bugs/1972654
Title:
[security review] Sync policyki
> There was a proposal to use duktape instead of mozjs for the JavaScript
> interpreter but I don't think that's been merged yet.
This was merged upstream, but unfortunately there has not yet been a
release that contains this change.
I don't really want to use an arbitrary git snapshot for securi
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.
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, pleas
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,
** 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.o
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), 0
** Changed in: dbus-python (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gedit-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1165742
Title:
Synctex plugin was not built in raring
Stat
0
Maintenance
===
- Actively developed upstream
https://github.com/projectatomic/bubblewrap
- Maintained in Debian by the pkg-utopia team but more specifically,
it is maintained by Simon McVittie (smcv) who also maintains Flatpak
and ostree in Debian and Ubuntu.
short
> 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
*** 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
[s
(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 ot
(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 h
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 "<" and ""
in both directions between Empathy and Pidgin, and check that neither is
> 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 b
(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 b
(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
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
'" or "the key whose fingerprint is ...
is controlled by th
(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
(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 in
(In reply to comment #68)
> It doesn't matter, if the message is in the form "?OTR:" 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 say
(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 deserv
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 De
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
+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 no
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 conne
(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
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_MES
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
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
(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
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.
+
+ (Gabble-specific)
If doing this in
MC correctly detects sleep...
> mcd-DEBUG: 05/10/2012 18:39:45.823941: notify_sleep_cb: about to sleep!
> sleep_kind=suspend
>mcd-DEBUG: 05/10/2012 18:39:45.824153: on_transport_status_changed: Transport
>i love the internet changed status to 2 (disconnected)
but before it resumes, it thinks yo
Guillaume appears to have fixed this in commit a5fb89b, which was in
Mission Control versions 5.12.2 and 5.13.1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-mission-control-5 in Ubuntu.
https://bugs.launchpad.net/bugs/993880
(In reply to comment #1)
> The only thing that I could
> get to trigger was if I set the 'Resource' in advanced configuration to
> 'laptop'. If I removed 'Resource' or changed it to '/laptop', then it
> worked. [...] I can say that perhaps it would be reasonable
> for empathy/telepathy-gabble to pr
(In reply to comment #10)
> Any updates here?
Not until/unless...
(In reply to comment #4)
> As discussed on IRC, the correct solution is not to copy certificates around
> wildly; it's to implement the API discussed on bug 29018.
... someone does that, and puts the result here for review.
(I do
(In reply to comment #7)
> Sure, I guess you meant 5.14 there?
Yes. Pushed to telepathy-mission-control-5.14 branch for the benefit of
anyone else still on that version. Thanks!
Regression somewhere in the 5.13/5.14 cycle, fixed in 5.14.2 in the
unlikely event that that version is ever released.
Probably worth backporting to 5.12, could you attach the exact patch you
applied please?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-mission-control-5 in Ubuntu.
https://bugs.launchpad.net/bugs/1217086
Title:
mission-cont
(In reply to comment #3)
> > The version of MC in raring appears to be from the middle of a development
> > branch
>
> you mean quantal I guess?
Sorry, yes, I meant MC 5.13 (or any future x.odd.z version).
--
You received this bug notification because you are a member of Desktop
Packages, which
(In reply to comment #3)
> (In reply to comment #0)
> > There's several bouncers that
> > support socks or by addition of a custom command "CONNECT" in the IRC
> > protocol that is used for selecting the target network that should be
> > used.
>
> Support for these would require use of a non-syste
*** Bug 37918 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-haze in Ubuntu.
https://bugs.launchpad.net/bugs/540536
Title:
Empathy does not support AIM buddy chat
Status in Te
*** Bug 47891 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/954918
Title:
Missing "Server" input box for Sametime accounts
Status in
Fixed in 0.7.1
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/954918
Title:
Missing "Server" input box for Sametime accounts
Status in Chat app, and Telepathy user interface:
Fix R
This was merged in the 0.16.x "old-stable" branch too, it's just waiting
for a release (0.16.7).
The same code might need similar modifications for Bug #39057.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-gabble in Ubuntu.
h
Looks like this could be Bug #50009, which was fixed in 5.12.2, 5.13.1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-mission-control-5 in Ubuntu.
https://bugs.launchpad.net/bugs/924468
Title:
Empathy doesn't reconnect afte
I'm going to assume this was fallout from "libdbus isn't actually
thread-safe".
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gvfs in Ubuntu.
https://bugs.launchpad.net/bugs/395216
Title:
SIGSEGV in dbus_address_entry_get_value()
St
What were the old account parameters called? What was their syntax?
What are the new account parameters called? What is their syntax?
Is there any way we can test Sametime without buying a server for it?
Does this untested patch work?
diff --git a/src/protocol.c b/src/protocol.c
index 639e25e..
h syntax like "username:server",
flagged as being split at ":" - to keep existing accounts working,
we want to separate them again, like we do for IRC.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=44631
Tested-by: Simone Caronni
Signed-off-by: Simon McVittie
--
Yo
(In reply to comment #4)
> Is the attached patch for telepathy-haze?
Yes.
> The old parameters were "account", "server", "port" and "password" IIRC.
>
> Now I have all of them except the "server" one, to make it work correctly I
> have to use the following syntax in the connection parameters dia
(In reply to comment #6)
> 1- When creating the account the only field is "account", no "server" field.
> 2- I edit the "connection settings" and fill in the fields.
> 3- It asks me for the password, and when filling it in it keeps on asking.
> 4- If I edit the account settings to re-check, all the
(In reply to comment #8)
> Thanks for the patch. Can you push it to telepathy-haze?
I can if someone reviews it (or tbh I'll push it after a while anyway,
if nobody actually wants to veto it).
> > (In reply to comment #6)
> > If you're giving Empathy a protocol-specific
> > UI for sametime anyway
0.20.3, 0.21.1.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/1064786
Title:
empathy-auth-client SIGABRT in tls_certificate_got_all_cb():
cert_data != NULL
Status in Chat app, an
Sure, let's have this. "Don't be remotely crashable" is among my D-Bus
design principles.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/1064786
Title:
empathy-auth-client SIGABRT in
Is this reproducible? If so, how?
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-mission-control-5 in Ubuntu.
https://bugs.launchpad.net/bugs/572737
Title:
mission-control-5 crashed with SIGSEGV in
g_cclosure_marshal_VOID_
(In reply to comment #2)
> The real fix would
> probably be making idle use glib's GSocketClient to leverage the recently
> added transparent proxy capabilities
This should now work (since 0.1.11), but that wasn't what was requested:
(In reply to comment #0)
> There's several bouncers that
> supp
Fixed in 0.16.3, 0.17.1. Cross-references: this bug is also Debian
#687370, LP: #984132.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-gabble in Ubuntu.
https://bugs.launchpad.net/bugs/984132
Title:
telepathy-gabble increas
>From the downstream bug, this was an error in the Ubuntu apparmor
profile, which we do not support.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-gabble in Ubuntu.
https://bugs.launchpad.net/bugs/1058768
Title:
telepathy-g
We're going to fix this by removing the gnome-keyring support instead
(Bug #32578). Empathy does its own keyring interaction now.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/556454
T
Here is the patch for this specific bug:
http://cgit.freedesktop.org/telepathy/telepathy-mission-
control/commit/?h=telepathy-mission-
control-5.12&id=eaefb264316f206186b2ac7f1f36e6a4692deb3d
although I recommend upgrading to 5.14.0 instead. 5.13.x were a
development branch and will not receive b
Public bug reported:
This is Debian #687933 and is fixed upstream in 5.12.3 and 5.13.2.
(We'll be doing a 5.14.0 stable-branch release shortly, with the same
code as 5.13.2.)
Steps to reproduce
==
* Have Empathy on an old Ubuntu version (Empathy 2.x) with an IM (e.g. Jabber)
acc
Fixed upstream in 5.13.2. It uses ~/.local/share, because accounts
aren't really configuration as such, but that's just as good from the
point of view of a "clean" home directory.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to telepathy-
** Bug watch added: freedesktop.org Bugzilla #54634
https://bugs.freedesktop.org/show_bug.cgi?id=54634
** Also affects: telepathy-gabble via
https://bugs.freedesktop.org/show_bug.cgi?id=54634
Importance: Unknown
Status: Unknown
--
You received this bug notification because you ar
(In reply to comment #4)
> To get the status of the requester visible, select one of your groups. After
> the status is visible it doesn't appear to matter weather a group is selected
> or not. When you decline the request in this state with the requesters on-line
> status visible the decline reque
(In reply to comment #25)
> Indeed, the problem is with non-MSN accounts, ICQ and Yahoo specifically.
Then that's not a Haze bug; please ask the developers of Pidgin
(libpurple) to support the virtual methods used by
purple_account_set_public_alias() in the ICQ and Yahoo prpls.
--
You received t
(In reply to comment #6)
> Note that in current libpurple, only the MSN prpl can take advantage of this.
Are you trying to set the alias of MSN or non-MSN accounts?
If you're trying to set the alias of non-MSN accounts and it doesn't
work, that probably means the prpl (libpurple protocol plugin)
(In reply to comment #4)
> This updated patch
Applied for 1.5.10, more or less (I also added a comment).
(In reply to comment #2)
> For 1.4.x it'd be better to make deprecated declarations non-fatal, or even
> just silence the warning altogether.
I did this for 1.4.18, and we should reapply this
Looks good for 1.5, I'll apply it there soon.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-utils in Ubuntu.
https://bugs.launchpad.net/bugs/911125
Title:
FTBFS due to removed g_thread_init
Status in D-Bus:
Confirmed
Status
(In reply to comment #1)
> This patch works, but it bumps the glib requirement for the tests to 2.31.4
I'd prefer it if this could be avoided, even for 1.5, until 2.32 exists
and has ABI stability.
--
You received this bug notification because you are a member of Desktop
Packages, which is subsc
(In reply to comment #1)
> If that's not appropriate, I could
> add some #if magic to emulate g_thread_new() with a macro that calls
> g_thread_create() if you are interested.
For 1.4.x it'd be better to make deprecated declarations non-fatal, or
even just silence the warning altogether. 1.4.x is
Requires general infrastructure for end-to-end security, which is Bug
#29904.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/296867
Title:
empathy needs to support OTR encryption
Sta
76 matches
Mail list logo
