*** 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
> [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
** Also affects: flatpak (Ubuntu)
Importance: Undecided
Status: New
** Package changed: flatpak (Ubuntu) => flatpak
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to appstream in Ubuntu.
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,
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),
** Changed in: dbus-python (Ubuntu)
Status: New => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to gedit-plugins in Ubuntu.
https://bugs.launchpad.net/bugs/1165742
Title:
Synctex plugin was not built in raring
> 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
(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
(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
(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
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
(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
(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
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
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
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
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),
+
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
(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
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
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,
(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
+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
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
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
(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
(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 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
(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-system-wide
Fixed in 0.7.1
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/954918
Title:
Missing Server input box for Sametime accounts
To manage notifications about this bug go to:
*** Bug 47891 has been marked as a duplicate of this bug. ***
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/954918
Title:
Missing Server input box for Sametime accounts
To
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 Ubuntu
Desktop Bugs, which is a bug assignee.
https://bugs.launchpad.net/bugs/395216
Title:
SIGSEGV in dbus_address_entry_get_value()
To manage
(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 dialog in the
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 simon.mcvit...@collabora.co.uk
--
You received this bug notification because
(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, you
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
(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 settings
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 Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/1064786
Title:
empathy-auth-client SIGABRT
(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
support
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 Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
(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 #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
(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
(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 a
(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 Ubuntu
Desktop Bugs, which is
Looks good for 1.5, I'll apply it there soon.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to evolution-webcal in Ubuntu.
https://bugs.launchpad.net/bugs/911125
Title:
FTBFS due to removed g_thread_init
To manage notifications
Requires general infrastructure for end-to-end security, which is Bug
#29904.
--
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/296867
Title:
empathy needs to support OTR encryption
This was bounced from project to project and ended up in telepathy-spec
at https://bugs.freedesktop.org/show_bug.cgi?id=30396.
However, I'm not sure whether this is actually relevant to telepathy-
spec, because I don't think the communication between Empathy and its
MSN backend should need to
An alternative course of action would be to give Telepathy messages a
flag similar to MSN's RL=1, which indicates the main context's writing
direction (as described in http://en.wikipedia.org/wiki/Bi-
directional_text).
Since I don't know how RTL languages work, I can't judge whether auto-
49 matches
Mail list logo
