Bug#1041269: hamster-time-tracker: hamster does not start

[Ulrike Uhlig]

Package: hamster-time-tracker
Version: 3.0.2-4
Severity: important

Dear Maintainer,

I installed hamster-time-tracker on a fresh installation of bookworm.

   * What led up to the situation?

Trying to launch hamster from either command line or Gnome, the program fails
to start.

   * What was the outcome of this action?

See errors related to dbus here: http://paste.debian.net/1286041/

   * What outcome did you expect instead?

I expect hamster to run out of the box or give me an actually readable error
message that doesn't require yakshaving :)


-- System Information:
Debian Release: 12.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-10-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hamster-time-tracker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-gtk-3.0   3.24.37-2
ii  libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii  libjs-jquery-ui  1.13.2+dfsg-1
ii  python3  3.11.2-1+b1
ii  python3-cairo1.20.1-5+b1
ii  python3-dbus 1.3.2-4+b1
ii  python3-distutils3.11.2-3
ii  python3-gi   3.42.2-3+b1
ii  python3-xdg  0.28-2

Versions of packages hamster-time-tracker recommends:
ii  gnome-shell-extension-hamster  0.10.0+git20210628-4
ii  yelp   42.2-1

hamster-time-tracker suggests no packages.

-- no debconf information

Bug#1002666: Still experiencing this issue?

[Ulrike Uhlig]

Hi Richard,

are you still experiencing this issue?
Or did you solve it differently?

(I was just going through bugs to see what can be cleaned up)

Ulrike

Bug#745661: Weblate packaging → Salsa?

[Ulrike Uhlig]

Hey,

On 20.01.22 15:10, Antoine Beaupré wrote:

On 2022-01-20 13:09:06, Ulrike Uhlig wrote:

On 19.01.22 16:25, Antoine Beaupré wrote:

On 2018-08-18 10:57:00, Ulrike Uhlig wrote:



https://salsa.debian.org/ulrike/weblate I added you as a maintainer there.


shouldn't we move this to the new "collab-maint" (the debian group on salsa)?


Feel free to move it anywhere you want. I just did the first and easiest 
thing that came to my mind.


Take care,
Ulrike

Bug#745661: Weblate packaging → Salsa?

[Ulrike Uhlig]

Hi Antoine,

On 19.01.22 16:25, Antoine Beaupré wrote:

On 2018-08-18 10:57:00, Ulrike Uhlig wrote:



Is anybody interested in this?


We (torproject.org) are.

Please do put your stuff on salsa, or alternatively someone could 
restore from the alioth backups, but I couldn't find it here:


https://alioth-archive.debian.org/git/repolist

Help! :)

(Arguably, the packaging would now be almost a decade old, but
there's some stuff like the description and copyright that we could
possibly reuse. Alternatively, maybe we could just do a py2dsp and be
done with it.)


Hey, this message of mine was only 3.5 years old and the last commit
dates back only 7.5 years! :) I have no memory of the state of the 
package from back then though, I let you explore.


https://salsa.debian.org/ulrike/weblate I added you as a maintainer there.

hugs,
Ulrike

Bug#882375: Thanks

[Ulrike Uhlig]

Hi Daniel,

On 22.03.21 19:02, asciiw...@seznam.cz wrote:

On Thu, 23 Nov 2017 14:16:00 + u  wrote:

thanks for your patch, I will try to add this as soon as I can, once
reviewed.



is there any progress regarding this? It has been almost three years and the 
AppStream metadata file still seems to be missing.


As I am not a pidgin user myself anymore, I'm not taking care of this 
package, even though I am still part of the privacy team.


To my knowledge, Clément (nodens) c/would potentially take care of it as 
part of his work.


Cheers!
Ulrike

Bug#983198: [Pkg-privacy-maintainers] Bug#983198: torbrowser-launcher: launcher does not detect torbrowser as installed on non-EN user session

[Ulrike Uhlig]

Hi Marcelo & Imre,

thank you for the report, patch and testing. I've for now forwarded your 
bug report and patch upstream where this should be fixed for real.


https://github.com/micahflee/torbrowser-launcher/issues/552

Care to create a pull request there yourself? Otherwise I can do that.

I haven't been participating in maintaining tbl in Debian for a while 
now. I would need some time to look at all the currently open bugs there 
before applying your patch and upload a new version - so I am not doing 
that right now.


Ulrike

Bug#964090: Status summary

[Ulrike Uhlig]

Hello!

As I ran into this issue I am giving here a short summary from what I 
understand to avoid that others have to re-read everything again:


AFAIU, there are two issues, one is related to Ghostscript, and one to 
ImageMagick itself.


Ghostscript
===

According to https://www.kb.cert.org/vuls/id/332928/ the issue is 
addressed in Ghostscript 9.24.


Except for Debian old-old-stable, Debian does ship versions above 9.24: 
https://tracker.debian.org/pkg/ghostscript


ImageMagick
===

Issue described here: 
https://insert-script.blogspot.com/2020/11/imagemagick-shell-injection-via-pdf.html


This is fixed in ImageMagick 6.9.11 and later, which is available in 
Bullseye but not earlier versions of Debian.


Current status reflected there:
https://security-tracker.debian.org/tracker/CVE-2020-29599


 - ulrike

Bug#965088: Re: [Pkg-privacy-maintainers] Bug#965088: Waiting for release 2.3

[Ulrike Uhlig]

Hello!


intrigeri: IMO, there's no rush and it's OK for us to delay the upgrade (and 
dealing with any Tails-specific integration work) until we upgrade to Bullseye. 
[11:42:15 AM] intrigeri: If we had any other need/requirement on this front, we 
would have let nodens know  [11:42:46 AM] intrigeri: Thanks for caring!


Thanks for the information.

On a sociological sidenote:
In FLOSS communities, silence (as in: absence of communication) is a 
means of communication which might have many different meanings and 
which exist on very different ends of a spectrum; on the one end there 
could be ignorance, forgetfulness, unavailability (even harder if one of 
the communicating parties is our single contact point, or SPOF), or even 
disagreement, while on the other end we can find agreement, implicit 
consent, the absence of (particular) needs, questions, or concerns.

Specifically on Debian mailing lists silence often means agreement.
I do find this hard to navigate sometimes! :)

Ulrike

Bug#965088: [Pkg-privacy-maintainers] Bug#965088: Waiting for release 2.3

[Ulrike Uhlig]

Hello,

On 22.02.21 21:34, Antoine Beaupré wrote:

On 2021-02-22 21:13:40, Diederik de Haas wrote:

On Sat, 14 Nov 2020 23:14:12 +0100 Ulrike Uhlig  wrote:

I did not forget about this, but I'm waiting for 2.3 to be released, as
there has been some huge refactoring which concerns the packaging of
Onionshare, see https://github.com/micahflee/onionshare/pull/1208.


Version 2.3 has been released (and tag added yesterday).
Is it too late for Bullseye?


Probably.


Indeed. I have no idea how much work is needed to update the Debian 
package with regard to the huge refactoring of the code in 2.3. (And if 
 that version number should have been a 3.0 instead…)


That said, we might be able to provide a backport, as this has been 
requested multiple times. Nodens could check with Tails if they would 
want a backport - which would make it more of a priority for us to 
maintain a backport.


Ulrike

Bug#981817: [Pkg-privacy-maintainers] Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

[Ulrike Uhlig]

Hi!

On 10.02.21 13:08, Jonathan Marquardt wrote:

On Wed, Feb 10, 2021 at 12:26:35PM +0100, nodens wrote:

Yes, the apparmor profile shipped with onioncircuit won't allow access
to stuff in /usr/local. So python interpreter can't actually run.



You're right. Just as a test i added "/usr/local/** r," to
/etc/apparmor.d/local/usr.bin.onioncircuits and it works now.


If you prefer, I could reopen the bug and tag it as wontfix for clarity.


I really don't care.

Thank you again! And thank you to Ulrike as well!


I'm glad this was solved! And somehow cooperatively, I like that :)

Ulrike

Bug#981817: onioncircuits: Permission denied: '/usr/local/lib/python3.7/dist-packages/psutil-5.7.2.dist-info'

[Ulrike Uhlig]

Hi!

On 10.02.21 00:18, Jonathan Marquardt wrote:

On Fri, Feb 05, 2021 at 12:08:49PM +0100, Clément Hermann wrote:

On 04/02/2021 13:04, Jonathan Marquardt wrote:

On Thu, Feb 04, 2021 at 12:23:17PM +0100, Clément Hermann wrote:



However I found out that it always works (on all of my systems) if I launch
onionciruits with the command:

$ python3 /usr/bin/onionciruits

I have no idea why.


Could this be related to AppArmor?

Just a random idea.

Ulrike

Bug#965088: Waiting for release 2.3

[Ulrike Uhlig]

Hi!

I did not forget about this, but I'm waiting for 2.3 to be released, as
there has been some huge refactoring which concerns the packaging of
Onionshare, see https://github.com/micahflee/onionshare/pull/1208.

Among other things, what was done there is:

* Renamed onionshare (former CLI) to onionshare-cli and onionshare-gui
  (former GUI) to just onionshare
* Rearranged the directory structure -- now the CLI project is in cli
  and the GUI project is in desktop
* Ported from PyQt5 to PySide2 -- these are two competing python
  bindings for Qt5, but PySide2 makes setting up a dev environment much
  simpler and works with Briefcase

greetings,
ulrike

Bug#972500: hamster-time-tracker does not launch on Buster using the backported package

[Ulrike Uhlig]

Hi!

thank you for the quick reply.

On 19.10.20 17:39, Raphael Hertzog wrote:

> Ulrike, did you restart your computer after the upgrade just to make sure
> that the dbus service was properly using the new code ?

I totally never reboot after installing packages, except for kernel
updates :) But but but! Rebooting actually worked! So no need to further
investigate that.

Thanks! <3
Ulrike

Bug#972500: hamster-time-tracker does not launch on Buster using the backported package

[Ulrike Uhlig]

Package: hamster-time-tracker
Version: 3.0.2-3~bpo10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

*** Reporter, please consider answering these questions, where
appropriate ***

   * What led up to the situation?

I'm trying to start hamster-time-tracker. I have used the program for
many years (as hamster-applet) and upgraded to the transitional package.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Trying to start the program is ineffective.
Trying to reinstall the program did not solve the issue.

   * What was the outcome of this action?
$ hamster
Traceback (most recent call last):
  File "/usr/bin/hamster", line 149, in on_activate_window
self._open_window(action.get_name(), data)
  File "/usr/bin/hamster", line 184, in _open_window
self.overview_controller = Overview()
  File "/usr/lib/python3/dist-packages/hamster/overview.py", line 477, in
__init__
self.find_facts()
  File "/usr/lib/python3/dist-packages/hamster/overview.py", line 531, in
find_facts
self.facts = self.storage.get_facts(start, end, search_terms=search)
  File "/usr/lib/python3/dist-packages/hamster/client.py", line 156, in
get_facts
for fact in self.conn.GetFactsJSON(dbus_range, search_terms)]
  File "/usr/lib/python3/dist-packages/hamster/client.py", line 99, in conn
server_version = self._connection.Version()
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in
__call__
return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 654, in
_message_cb
(candidate_method, parent_method) = _method_lookup(self, method_name,
interface_name)
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 246, in
_method_lookup
raise UnknownMethodException('%s is not a valid method of interface
%s' %
(method_name, dbus_interface))
UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown
method: Version is not a valid method of interface org.gnome.Hamster

Traceback (most recent call last):
  File "/usr/bin/hamster", line 149, in on_activate_window
self._open_window(action.get_name(), data)
  File "/usr/bin/hamster", line 184, in _open_window
self.overview_controller = Overview()
  File "/usr/lib/python3/dist-packages/hamster/overview.py", line 477, in
__init__
self.find_facts()
  File "/usr/lib/python3/dist-packages/hamster/overview.py", line 531, in
find_facts
self.facts = self.storage.get_facts(start, end, search_terms=search)
  File "/usr/lib/python3/dist-packages/hamster/client.py", line 156, in
get_facts
for fact in self.conn.GetFactsJSON(dbus_range, search_terms)]
  File "/usr/lib/python3/dist-packages/hamster/client.py", line 99, in conn
server_version = self._connection.Version()
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 70, in
__call__
return self._proxy_method(*args, **keywords)
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 145, in
__call__
**keywords)
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 651, in
call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod:
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 654, in
_message_cb
(candidate_method, parent_method) = _method_lookup(self, method_name,
interface_name)
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 246, in
_method_lookup
raise UnknownMethodException('%s is not a valid method of interface
%s' %
(method_name, dbus_interface))
UnknownMethodException: org.freedesktop.DBus.Error.UnknownMethod: Unknown
method: Version is not a valid method of interface org.gnome.Hamster

   * What outcome did you expect instead?

Package should work. Reinstalling should install, or propose missing
libraries,
or software if any.

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 10.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-11-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages hamster-time-tracker depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  libjs-jquery 3.3.1~dfsg-3
ii  libjs-jquery-ui  1.12.1+dfsg-5
ii  python3

Bug#965150: onionshare --local-only connects to Tor Fixed upstream

[Ulrike Uhlig]

This was apparently fixed upstream:
https://github.com/micahflee/onionshare/issues/1149#issuecomment-661668433
So it will be in OnionShare 2.3 in Debian.

Bug#965152: onionshare man page: undocumented --website

[Ulrike Uhlig]

On 17.07.20 13:11, Jakub Wilk wrote:
> * Ulrike Uhlig , 2020-07-17, 11:18:
>> I've fixed this already in
>> https://salsa.debian.org/pkg-privacy-team/onionshare/-/compare/a97caf90bf600175591c22d5695a62b69d9c8725...6e950f3ad7201836e8dab6080990f94b9384b9d9
>>
>> and will release that along with the separation of GUI and CLI interface.
> 
> e89cc7c4b9365c8b indeed added description of the website mode; but it
> doesn't explain how to turn it on. There's still no mention of the
> option in git HEAD:
> 
>   $ git describe
>   debian/2.2-2-5-ge9b2131
> 
>   $ man -l debian/onionshare.1 | grep -c -- --website
>   0

Feel free to contribute via salsa:

https://salsa.debian.org/pkg-privacy-team/onionshare/-/commit/48f184e5f6dc814d020c2a25bbcfc11fc735d629


:)

 - ulrike

Bug#965055: onionshare man page: "crypto key lives in /tmp/onionshare/tmpXXX/private_key"

[Ulrike Uhlig]

On 17.07.20 11:31, Jakub Wilk wrote:
> * u , 2020-07-17, 11:10:
 The onionshare(1) man page says: "the crypto key lives in
 /tmp/onionshare/tmpXXX/private_key". I don't belive this is correct.
>>> The onionshare-gui(1) man page includes this sentence too.
>> Yes, I'm well aware of it and fixed that in my commit from two days
>> ago :)
> 
> Hmm, did you? I still see this in git HEAD:
> 
>   $ git describe
>   debian/2.2-2-4-g6e950f3
> 
>   $ man -l debian/onionshare-gui.1 | grep -oE '/tmp/(/|\w)+'
>   /tmp/onionshare/tmpXXX/private_key

Good catch, apparently I forgot to commit + push that. Done now.

 - ulrike

Bug#965150: onionshare --local-only connects to Tor

[Ulrike Uhlig]

Hello,

On 16.07.20 23:11, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> 
> "onionshare --local-only" doesn't start an onion service (as expected),
> but it still connects to the Tor network. This is weird.

Weird indeed. I've forwared that bug upstream.

 - ulrike

Bug#965152: onionshare man page: undocumented --website

[Ulrike Uhlig]

Hi Jakub!

On 16.07.20 23:21, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: minor
> 
> The --website option is not documented in the manual page.

This was missed when the new version was uploaded.

I've fixed this already in
https://salsa.debian.org/pkg-privacy-team/onionshare/-/compare/a97caf90bf600175591c22d5695a62b69d9c8725...6e950f3ad7201836e8dab6080990f94b9384b9d9
and will release that along with the separation of GUI and CLI interface.

°x°
 - ulrike

Bug#965055: Incorrect manpage reference to crypto key: Will be fixed in new release

[Ulrike Uhlig]

I addressed this issue by rewriting the manpage to make it more
up-to-date and reflect the features of the current version of onionshare.

See
https://salsa.debian.org/pkg-privacy-team/onionshare/-/compare/a97caf90bf600175591c22d5695a62b69d9c8725...6e950f3ad7201836e8dab6080990f94b9384b9d9
for details.

Bug#965088: onionshare: please demote python3-pyqt5

[Ulrike Uhlig]

Hi Jakub!

On 15.07.20 23:04, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: wishlist
> 
> onionshare has currently python3-pyqt5 in Depends. But as I understand
> it, this package is only needed for the GUI, whereas the CLI could work
> fine without it. I'd like to run onionshare on a headless system without
> installing hundreds of megabytes of X11 and Qt libraries.
> 
> Please consider either demoting python3-pyqt5 to Recommends or putting
> the GUI and the CLI in separate packages.

I think this is a very valid usecase. Thank you for bringing it up.
I can try to look into that soonish.

Ulrike

Bug#965055: onionshare man page: "crypto key lives in /tmp/onionshare/tmpXXX/private_key"

[Ulrike Uhlig]

Hi!

On 15.07.20 11:30, Jakub Wilk wrote:
> Package: onionshare
> Version: 2.2-2
> Severity: minor
> 
> The onionshare(1) man page says: "the crypto key lives in
> /tmp/onionshare/tmpXXX/private_key". I don't belive this is correct.

Thank you for reporting this bug.

I guess this phrase is very old information and needs to be fixed or
deleted altogether.

Ulrike

Bug#954209: Do we want to add a fork of utls (ITP #954209)?

[Ulrike Uhlig]

Hi Ana!

On 03.04.20 15:36, Ana Custura wrote:
> On 16/03/2020 18:12, Ulrike Uhlig wrote:
> 
>> If I understand correctly from a quick look, Yawning distributes his
>> changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
>> [https://github.com/refraction-networking/utls/blob/master/LICENSE].
>>
>> The BSD 3-Clause is in line with the Debian Free Software Guidelines
>> (DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].
>>
>> From my understanding, in Debian packaging, licenses generally apply to
>> files but it also seems possible (I never encountered such a case) to
>> have several licenses for one file
>> [https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
>> Maybe someone could confirm that this is accepted.
>>
>> I'm now unsure to what we referred to previously when saying that there
>> might be licensing issues with Yawning's fork. It does not look like
>> there are. Or am I missing something crucial here? If I don't, then to move 
>> forward, one would need to open an RFP or ITP
>> (Intent to Package) bug on the Debian bugtracker and then package this
>> fork of uTLS.
> To sum up the concerns that came from looking at it last time:
> 
> golang-yawning-utls-dev is a fork of utls, which is itself a fork of the
> golang tls library. This is a hard fork, any improvements cannot be
> shipped upstream due to the difference in licensing that you've
> identified. The upstream is very active - go has >1500 contributors,
> uTLS has >50 contributors. The fork we want to package is maintained by
> very few people, if I'm not mistaken, Yawning is the only core contributor.

While this is not ideal, there are other packages in Debian that suffer,
or have suffered, from a similar setup, like torbrowser-launcher, or
onionshare.

> I think there is a security implication here - if there is a security
> advisory for the golang library, the Debian Security team needs to work
> with the upstreams to apply security patches to it and all of its forks
> in Debian, meaning this one too. If the delta from upstream increases
> with every fork this could mean a lot of pain.

On https://wiki.debian.org/Teams/Security I read:

For stable: "The preferred situation is that the regular maintainer of
an affected package (who is most familiar with its ins and outs)
prepares updated packages or a ready to use patch which, after approval,
will be uploaded to security-master. If the regular maintainer can't or
won't provide updates (in time), the security team will take the task of
creating the updated packages.

Security for testing and unstable is not officially guaranteed, but the
team tracks those distributions as well in the security tracker. "

However, I think it would be useful that the person maintaining that
package also has an eye on the golang TLS library, to be informed early
on about potential security issues. (I could not find that package in
the Debian archive, and as I'm totally unfamiliar with Go, I wouldn't
know how to monitor that situation.)

It would be helpful if the Debian package maintainer could create pull
requests, or at least open issues, on yawning's repository, when a
security issue is reported.

My understanding is that this does not prevent us from uploading the
package to the Debian archive, as long as Yawning's code is actively
maintained.

Correct me if I'm wrong.

> However, my understanding of the dynamics could be entirely wrong, so
> let me know if I'm off the mark.

> Sending this to the Debian Security team, to ask if they see any
> problems here. Including the source link:
> https://gitlab.com/yawning/utls and ITP:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954209

Good idea.

> If we're all good, I'd be very happy to help with packaging or even
> sponsoring this (I've recently completed the process to become DD, now
> under review!).

I'm very happy to read this. Congratulations! :)

>> → actually that package was uploaded to mentors.debian.org and could go
>> to experimental.
> Happy to update this to the latest policy and reupload if this is
> something we want to do.

Yay from me. Let's see if anyone else, besides the security team, has a
comment on this.

>>> Hey, I'm new to the debian packaging space but am happy to help out here.
> Awesome, thank you for helping with this :)

Cheers!
ulrike

PS: Ana, are you subscribed to
pkg-privacy-maintain...@alioth-lists.debian.net or do you prefer to be
Cc:ed?

Bug#955821: [Pkg-privacy-maintainers] Bug#955821: torbrowser-launcher: include upstream patch to allow access to u2f tokens

[Ulrike Uhlig]

Hi Birger!

> it would be great if U2F devices (like a yubikey) would be usable by
> default with torbrowser. I created an upstream merge request to allow
> these devices in the apparmor profile a couple of months ago and it was
> was merged [0] (thanks to intrigeri!), but there was no new torbrowser
> release since then.
> Would it be possible to include the patch in the debian package? That
> would allow using salsa with U2F tokens (and any other Gitlab instance
> that might come up ;))

> [0] https://github.com/micahflee/torbrowser-launcher/pull/434

Great!

How do you feel about creating a pull request on
https://salsa.debian.org/pkg-privacy-team/torbrowser-launcher ?

If people on the privacy team list agree, we can give you access to the
repository.

Cheers!
u.

Bug#948312: Licensing questions Bug#948312: obfs4proxy: New upstream releasse

[Ulrike Uhlig]

Hi Cecylia!

On 16.03.20 18:24, Cecylia Bocovich wrote:
> On Tue, 7 Jan 2020 10:36:20 +0100 Ulrike Uhlig  wrote:
>> On 07.01.20 10:14, Ulrike Uhlig wrote:
>>> On 07.01.20 00:57, Chris Lamb wrote:

>>>> There is a new upstream release of obfs4proxy available (at the time
>>>> of writing, 0.0.11):>> However, this will require the packaging of
> at least https://gitlab.com/yawning/utls.
>>>
>>> Quoting Ana Custura:
>>>
>>> "
>>> We have 2 options going forward: we can package yawning's fork of uTLS
>>> or we can drop meek-lite support from the obfs4proxy package. We need to
>>> carefully consider this, as it is the only meek client currently
>>> packaged in Debian. I have built a package that drops meek-lite support
>>> (which is easily disabled) of version 0.0.11.

→ actually that package was uploaded to mentors.debian.org and could go
to experimental.

>>> There are some licensing issues that need to be resolved with yawning's
>>> fork of uTLS [3] before we consider looking at packaging it.

>> Tor seems to have had plans to help with the maintenance apparently:
>> https://trac.torproject.org/projects/tor/ticket/29286

> Hey, I'm new to the debian packaging space but am happy to help out here.

Yay! That is very nice, welcome.

> FWIW, there is active interest in a meek client package for Debian [1].

To this I would add the link to the Debian Request For Package (RFP)
bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764007. I haven't
looked at it in detail yet and I don't know if it adds up-to-date
supplementary info to the Torproject bug report.

> Before going forward with dropping it from the obfs4proxy package, we
> should probably have a meek package to take it's place. I've no idea how
> many tools rely on this feature of obfs4proxy but don't want to assume none.
> 
> If I understand correctly, the main blocker on this is licensing
> concerns around Yawning's fork of utls? Perhaps it's better to resolve
> this as the path forward. I'll take a look and see what we can do about
> this.

If I understand correctly from a quick look, Yawning distributes his
changes under GNU GPL, while uTLS upstream has a BSD 3-Clause license
[https://github.com/refraction-networking/utls/blob/master/LICENSE].

The BSD 3-Clause is in line with the Debian Free Software Guidelines
(DFSG)[https://wiki.debian.org/DFSGLicenses#The_BSD-3-clause_License].

>From my understanding, in Debian packaging, licenses generally apply to
files but it also seems possible (I never encountered such a case) to
have several licenses for one file
[https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax].
Maybe someone could confirm that this is accepted.

I'm now unsure to what we referred to previously when saying that there
might be licensing issues with Yawning's fork. It does not look like
there are. Or am I missing something crucial here?

If I don't, then to move forward, one would need to open an RFP or ITP
(Intent to Package) bug on the Debian bugtracker and then package this
fork of uTLS.

best,
ulrike

> [1] https://trac.torproject.org/projects/tor/ticket/13160

Bug#953148: RM: torbirdy -- ROM; Package is obsolete

[Ulrike Uhlig]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: pkg-privacy-maintain...@alioth-lists.debian.net

Torbirdy is not compatible anymore with Thunderbird 68+ and the features
of Torbirdy cannot be ported to a new-style Thunderbird addon.

Therefore there is no use in keeping the package in the Debian
repository any longer.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945456 and
https://redmine.tails.boum.org/code/issues/17219

Thank you!



signature.asc
Description: OpenPGP digital signature

Bug#945456: Resetting severity

[Ulrike Uhlig]

Hi!

As Thunderbird 60 is still available in testing, torbirdy should be able
to migrate there. This way, upon updating to TB68, users will at least
get a warning that torbirdy is not compatible anymore instead of having
the package removed automatically, and maybe falsely assuming that they
are still using Tor when sending emails, which could compromise privacy.

When Thunderbird 68 has finally migrated to testing, we can proceed to
remove torbirdy from the archive.

If you have better ideas on how to do this, let me know.

-- ulrike

Bug#948312: [Pkg-privacy-maintainers] Bug#948312: obfs4proxy: New upstream releasse

[Ulrike Uhlig]

On 07.01.20 10:14, Ulrike Uhlig wrote:
> On 07.01.20 00:57, Chris Lamb wrote:

>> There is a new upstream release of obfs4proxy available (at the time
>> of writing, 0.0.11):>> However, this will require the packaging of at least 
>> https://
>> gitlab.com/yawning/utls.
> 
> Quoting Ana Custura:
> 
> "
> We have 2 options going forward: we can package yawning's fork of uTLS
> or we can drop meek-lite support from the obfs4proxy package. We need to
> carefully consider this, as it is the only meek client currently
> packaged in Debian. I have built a package that drops meek-lite support
> (which is easily disabled) of version 0.0.11.
> 
> There are some licensing issues that need to be resolved with yawning's
> fork of uTLS [3] before we consider looking at packaging it.

Thinking about this a bit more I think it might also be worth asking Tor
(for example via irl@d.o or Philipp Winter, the lead of the censorship
team at Tor, https://nymity.ch/contact.txt) if they have a preferred way
of moving forward.

Tor seems to have had plans to help with the maintenance apparently:
https://trac.torproject.org/projects/tor/ticket/29286

 -- ulrike

Bug#948312: [Pkg-privacy-maintainers] Bug#948312: obfs4proxy: New upstream releasse

[Ulrike Uhlig]

Hi!

On 07.01.20 00:57, Chris Lamb wrote:
> Package: obfs4proxy
> Version: 0.0.8-1
> Severity: wishlist
> 
> There is a new upstream release of obfs4proxy available (at the time
> of writing, 0.0.11):
> 
>   https://qa.debian.org/cgi-bin/watch?pkg=obfs4proxy
> 
> However, this will require the packaging of at least https://
> gitlab.com/yawning/utls.

Quoting Ana Custura:

"
We have 2 options going forward: we can package yawning's fork of uTLS
or we can drop meek-lite support from the obfs4proxy package. We need to
carefully consider this, as it is the only meek client currently
packaged in Debian. I have built a package that drops meek-lite support
(which is easily disabled) of version 0.0.11.

There are some licensing issues that need to be resolved with yawning's
fork of uTLS [3] before we consider looking at packaging it.

Ana

[2] https://mentors.debian.net/package/obfs4proxy

[3] https://gitlab.com/yawning/utls#why-dont-you-upstream-the-changes
"

Bug#945456: xul-ext-torbirdy: Torbirdy is incompatible with Thunderbird > 60

[Ulrike Uhlig]

Package: xul-ext-torbirdy
Version: 0.2.6-1
Severity: important

Thunderbird is removing support for XUL extensions from version 68.
While there might be a possibility to convert Torbirdy to what
Thunderbird now calls MailExtensions and run the code of the extension
as legacy code, this would only have an effect within a limited
timeframe: Thunderbird will entirely remove support for legacy
extensions in version 72 or 78 (planned for summer 2020).

According to research of segfault from Tails, it seems impossible to
even set the preferences that Torbirdy set via this new MailExtension
format.

Some more detailed explanations can be found here:
https://redmine.tails.boum.org/code/issues/17149#note-6

Upstream bug: https://trac.torproject.org/projects/tor/ticket/31341

Bug#942797: RM: obfsproxy --ROM; upstream abandoned development

[Ulrike Uhlig]

Package: ftp.debian.org
Severity: normal

The Tor project does not develop nor deploy obfsproxy anymore, see
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/list
(obfs2, obfs3)

Last upstream commit happened 5 years ago.
https://gitweb.torproject.org/pluggable-transports/obfsproxy.git

Last upload to Debian happened 2 years ago.

The maintainer group pkg-privacy-maintain...@lists.alioth.debian.org has
since become the Privacy packaging team
(https://salsa.debian.org/pkg-privacy-team), which I am part of. The
team agrees to request the removal of obfsproxy.

FTR Last time it was discussed¹ in the team, it was clear that obfsproxy
was obsolete, but fteproxy was blocking the removal; since then,
fteproxy got removed from testing and sid, and according to dak² there's
no blocker anymore for removal.

Cheers,
ulrike

[1] discussion starts at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884043#56
[2] ssh mirror.ftp-master.debian.org dak rm -Rn obfsproxy



signature.asc
Description: OpenPGP digital signature

Bug#942790: RM: tails-installer -- ROM; Package is obsolete

[Ulrike Uhlig]

Package: ftp.debian.org
Severity: normal

Tails has discontinued releasing ISO images for USB sticks at the
beginning of 2019. Because of this, using this package has in fact
become obsolete.

Tails and Ulrike do not want to maintain this package in Debian anymore.

Upstream bug:
https://redmine.tails.boum.org/code/issues/16012

Thank you!



signature.asc
Description: OpenPGP digital signature

Bug#777382: O: dogtail

[Ulrike Uhlig]

Hi!

On 31.07.19 11:30, Samuel Thibault wrote:
> Ulrike Uhlig, le mer. 31 juil. 2019 11:20:38 +0200, a ecrit:
>> On 30.07.19 18:07, Samuel Thibault wrote:
>>> Since python2 packages are being phased out, perhaps we can simply
>>> directly move to python3-dogtail, or do some people still need a
>>> python-dogtail package? (there are no rdeps in Debian itself).
>>
>> I think this is indeed desirable.
> 
> Which one do you think is desirable? :)
> 
> - directly move to python3-dogtail, or
> - have a python-dogtail for some time.

Sorry if my reply was unclear: I think it's fine to move to
python3-dogtail directly.

Cheers!
Ulrike

Bug#777382: O: dogtail

[Ulrike Uhlig]

Hi Samuel,

On 30.07.19 18:07, Samuel Thibault wrote:
> Control: retitle -1 ITA: dogtail
> Control: owner -1 sthiba...@debian.org
> Control: tags -1 + pending
> 
> Hello,
> 
> intrigeri, le sam. 30 juil. 2016 14:14:16 +0200, a ecrit:
>> Maybe start by pushing to a Vcs-Git in collab-maint?
> 
> A repository was created by Ulrike Uhlig in January.  I have now
> populated it a bit more, notably with the packaging history, and added
> the repo URL in its contrib.

Great, thank you!

I have done some work on the packaging locally, but I haven't pushed it
to the repository because I did not have time to test what I did and if
I remember correctly, after merging the new upstream version, patches
needed updates and the package did not build correctly anymore.
(January?! Wow, that was a long time ago and this feels really stupid to
not have finished this work). I'll send you my modifications and you can
use whatever you need and what makes sense to you (I updated some
patches, added gbp.conf, updated from upstream).

> Since python2 packages are being phased out, perhaps we can simply
> directly move to python3-dogtail, or do some people still need a
> python-dogtail package? (there are no rdeps in Debian itself).

I think this is indeed desirable.

> At any rate, I can adopt this package.

Yay!

Cheers,
Ulrike

Bug#777382: O: dogtail

[Ulrike Uhlig]

Hi again!

Pushed my modifications to salsa.d.o:debian/dogtail → branch debian/sid.

I let you judge what you can reuse and what stinks → please remove it,
as said previously, I did not manage to build, because patches need updates.

Cheers
Ulrike

Bug#930448: [Pkg-privacy-maintainers] Bug#930448: onioncircuits: autopkgtest seems to be unreliable

[Ulrike Uhlig]

Hi!

On 12.06.19 23:10, Simon McVittie wrote:
> Source: onioncircuits
> Version: 0.5-4
> Severity: important
> User: debian...@lists.debian.org
> Usertags: flaky
> 
> The onioncircuits autopkgtest seems to fail occasionally, then succeed
> when retried. Because the unstable-to-testing migration software now
> blocks on regressions in testing, flaky tests, i.e. tests that flip
> between passing and failing without changes to the list of installed
> packages, can be problematic for the release process. Please either fix
> the test to be more robust, or mark this particular test as "flaky" like
> .

debian/changelog says

onioncircuits (0.5-4) unstable; urgency=medium

  * Make autopkgtest more resilient when circuits are missing.
Closes: 909275
  * Remove flaky flag for autopkgtest for now.

 -- Sascha Steinbiss   Sun, 10 Feb 2019 09:21:55 +0100

But it lacks an explanation why the flaky flag was removed.

Cheers!
u.

Bug#881496: No updates → closing

[Ulrike Uhlig]

No news on this bug since 1 year and unreproducible by Sascha and
intrigeri → I propose to close this bug.

Bug#926042: [Pkg-privacy-maintainers] Bug#926042: drawbacks of not having tbl in testing..

[Ulrike Uhlig]

Hi!

On 27.05.19 15:02, Holger Levsen wrote:
> On Mon, May 27, 2019 at 02:18:54PM +0200, Ulrike Uhlig wrote:
>> It would be useful to know with which statements or assumptions you do
>> not agree with and why - so that the discussion may become more
>> productive & helpful.
>  
> "cannot be maintained in stable". I think this can at least be tried.
> And IMO its better to have tbl in stable until the 5th or 7th
> pointrelease and then have it removed (if it has to be done), than not
> having tbl at all, never.
> 
>>> anyway, i just want to point out that 'maintaining tbl in stretch via
>>> stretch-backports' doesnt work because tbl is not in buster and thus, if
>>> this bug gets retitled to 'tbl should not be part of bullseye',
>>> maintaining tbl in buster via bullseye-backports will also not work.
>> Do you have any suggestion on how to handle this?
> 
> maintain tbl in stable.

I have re-read intrigeri's arguments [1] and I entirely agree with his
assessments:

1. updates are required because of changes of GPG keys, TLS certs etc.
2. apparmor profiles regularly need updates because of upstream changes
   that we are generally not made aware of in time by upstream and only
   discover after the fact. There is a huge lack of communication here.
3. lack of time & energy to backport fixes on a regular basis.

i.e. I don't see us maintaining tbl in stable. That is certainly a sad
state. But reality is that most of us have too many other things on
their plate and do not see this as a priority. I volunteer to update the
Debian wiki page to document how to install torbrowser-launcher once
Buster is out.

That said, if *you* want to maintain tbl in stable I have no objections.

Cheers!
Ulrike

[1] Message-Id: <87zhpcb569.fsf@manticora>, email from march 30, 2019

Bug#926042: drawbacks of not having tbl in testing..

[Ulrike Uhlig]

Hi Holger,

On 27.05.19 11:56, Holger Levsen wrote:
> i'm not sure I agree with the assumptions from this bug report but

It would be useful to know with which statements or assumptions you do
not agree with and why - so that the discussion may become more
productive & helpful.

> anyway, i just want to point out that 'maintaining tbl in stretch via
> stretch-backports' doesnt work because tbl is not in buster and thus, if
> this bug gets retitled to 'tbl should not be part of bullseye',
> maintaining tbl in buster via bullseye-backports will also not work.

Do you have any suggestion on how to handle this?

Cheers,
Ulrike

Bug#929023: unblock: bilibop/0.5.6

[Ulrike Uhlig]

Package: release.debian.org
Version: 0.5.6
Severity: normal

Please unblock package bilibop. I've uploaded 0.5.6 to unstable some
minutes ago.

Two bugs of severity important have been reported against bilibop-lockfs
few days ago and would be fixed by this upload:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928658
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928780

Both bugs are about boot failures when installing a fresh version of
Buster and this package. A source debdiff is attached.

Cheers,
Ulrike

unblock bilibop/0.5.6
diff -Nru bilibop-0.5.6/debian/changelog bilibop-0.5.5/debian/changelog
--- bilibop-0.5.6/debian/changelog	2019-05-11 03:40:04.0 +0200
+++ bilibop-0.5.5/debian/changelog	2019-01-31 00:52:22.0 +0100
@@ -1,15 +1,3 @@
-bilibop (0.5.6) unstable; urgency=high
-
-  * bilibop-lockfs:
-- fix boot failure by supporting the new path /usr/bin/mount as well as
-  the legacy /bin/mount (kept for backward compatibility).
-  Closes: #928658.
-- fix boot failure about mounts flagged 'ro' in fstab by applying the
-  'ro' option to the union instead of its writable branch.
-  Closes: #928780.
-
- -- Yann Amar   Sat, 11 May 2019 01:40:04 +
-
 bilibop (0.5.5) unstable; urgency=low
 
   * debian/control:
diff -Nru bilibop-0.5.6/lib/bilibop/lockfs_mount_helper bilibop-0.5.5/lib/bilibop/lockfs_mount_helper
--- bilibop-0.5.6/lib/bilibop/lockfs_mount_helper	2019-05-11 03:40:04.0 +0200
+++ bilibop-0.5.5/lib/bilibop/lockfs_mount_helper	2017-09-11 20:52:36.0 +0200
@@ -54,17 +54,11 @@
 }
 # ===}}}
 
-# Works only if the parent process is the mount command (/bin/mount for backward
-# compatibility, or /usr/bin/mount). This will ensure arguments are passed in a
-# specific order, and shorten the code to parse them.
-case "$(readlink -f /proc/${PPID}/exe)" in
-"/bin/mount"|"/usr/bin/mount")
-;;
-*)
-usage >&2
-exit 3
-;;
-esac
+# Works only if the parent process is /bin/mount:
+if [ "$(readlink -f /proc/${PPID}/exe)" != "/bin/mount" ]; then
+usage >&2
+exit 3
+fi
 
 . /lib/bilibop/common.sh
 get_bilibop_variables
@@ -188,32 +182,31 @@
 mntpnt="${2}"
 options="${4}"
 
-# Parse mount options and allocate them to the proper branches or their
-# union:
+# Parse mount options. Two cases:
 # 1. the block device will be mounted with the same options than in the
 #original fstab entry, plus 'ro'.
 # 2. the tmpfs will be mounted with only some options of the previous:
-#nodev, noexec, nosuid, if they exist.
-# 3. when set in the persistent fstab, the ro flag could be deferred to
-#the tmpfs mount (and the union will inherit of it), but this would
-#forbid creation of subdirectories for submountpoints.
+#ro, nodev, noexec, nosuid, if they exist.
 
 for opt in $(IFS=','; echo ${options}); do
+# 1. Options for the readonly branch:
 case "${opt}" in
 fstype=*)
 eval "${opt}"
 ;;
 rw)
 ;;
-ro)
-union_opts="${union_opts:+${union_opts},}${opt}"
+*)
+robr_opts="${robr_opts:+${robr_opts},}${opt}"
 ;;
-nodev|noexec|nosuid)
+esac
+
+# 2. Options for the writable branch:
+case "${opt}" in
+ro|nodev|noexec|nosuid)
 rwbr_opts="${rwbr_opts:+${rwbr_opts},}${opt}"
-robr_opts="${robr_opts:+${robr_opts},}${opt}"
 ;;
 *)
-robr_opts="${robr_opts:+${robr_opts},}${opt}"
 ;;
 esac
 done
@@ -381,9 +374,9 @@
 
 # Now set the union filesystem mount options
 if [ "${METHOD}" = "aufs" ]; then
-UNIONFS_OPTS="${union_opts:+${union_opts},}br:${rwbr}=rw:${robr}=${RO}"
+UNIONFS_OPTS="br:${rwbr}=rw:${robr}=${RO}"
 elif [ "${METHOD}" = "overlay" ]; then
-UNIONFS_OPTS="${union_opts:+${union_opts},}lowerdir=${robr},upperdir=${rwbr},workdir=${work}"
+UNIONFS_OPTS="lowerdir=${robr},upperdir=${rwbr},workdir=${work}"
 fi
 
 # Try to mount the union fs now. In case of failure, undo what has been done
diff -Nru bilibop-0.5.6/lib/bilibop/lockfs.sh bilibop-0.5.5/lib/bilibop/lockfs.sh
--- bilibop-0.5.6/lib/bilibop/lockfs.sh	2019-05-11 03:40:04.0 +0200
+++ bilibop-0.5.5/lib/bilibop/lockfs.sh	2017-09-11 20:52:36.0 +0200
@@ -319,7 +319,6 @@
 #!/bin/sh
 # THIS IS A FALLBACK; IT DON'T LOCK FS BUT JUST RECALLS /bin/mount WITH VALID FSTYPE AND OPTIONS.
 PATH="/bin"
-[ "\$(readlink -f /proc/\${PPID}/exe)" = "/usr/bin/mount" ] ||
 [ "\$(readlink -f /proc/\${PPID}/exe)" = "/bin/mount" ] || exit 3
 for opt in \$(IFS=',' ; echo \${4}) ; do
 case "\${opt}" in


signature.asc
Description: OpenPGP digital signature

Bug#928178: apparmor: thunderbird fails to start, saying that is already running

[Ulrike Uhlig]

Hi!

On 02.05.19 08:51, Piviul wrote:
> Il 30/04/19 18:45, Carsten Schoenert ha scritto:
>> Am 30.04.19 um 16:00 schrieb Piviul:
>>> Il 30/04/19 15:00, Carsten Schoenert ha scritto:

[...]
> stop and the cause is an unusual home path of remote users. You show me
> that was possible to add my remote user's homes to the paths of user's
> homes in AA. I have discovered AA and I have enabled it in others TB in
> my PCs and I have appreciated very much the effort you are doing to
> enforce the security in linux systems :)

:)

> Well, but who has enabled AA in PC? I'm sure that I have not worked on
> /etc in these days and I am the only one can access on it. In my opinion
> there is a bug in some package update that has enabled TB AA profile...
> but in effect I realize that to be believable someone else would find
> this unbelievable behaviour...

Maybe you accidentally upgraded to Buster or you are using a kernel that
has AA enabled by default.

Cheers!
u.

Bug#928178: apparmor: thunderbird fails to start, saying that is already running

[Ulrike Uhlig]

Hi!

On 30.04.19 09:31, Piviul wrote:
> Il 30/04/19 07:51, Carsten Schoenert ha scritto:

>> downgrading severity as AppArmor isn't officially supported and
>> activated for the Thunderbird package.
> but I'm not the one that activated apparmor for thunderbird: AFAIK in
> debian stretch (debian stable) the apparmor profile is enabled by default!

There are two things:

- installing and activating AppArmor
- activating a profile to confine a given software

The latter is sometimes done by packages but only takes effect if you
did the former.

In Stretch, AppArmor is not activated by default. Did you activate it
and use it for other software?

>> [...] The path to your profile looks unusual. In the past we had other
>> reports
>> that have show that AA isn't happy if the Thunderbird profile can't be
>> found in the typical folder.
> is unusual for local users but is a standard path for remote users where
> PCs are joined to a samba domain or where authentication is preformed
> remotely.

Your folder path was:
name="/home/DOMINIOCSA/psala/.thunderbird/5p9oab1n.default/.parentlock"

The issue is the "psala", that does not look like a standard path to me,
or is there a software which creates such a folder? And as you say below

> local users doesn't
> have problem using TB even with apparmor profile enabled.

So to me it sounds like a non-issue. You can add a local AppArmor file
for your setup, that would allow the path you're using. So you won't
have to disable the profile altogether. In summary, it does not look
like a bug in the AppArmor profile of Thunderbird at first glance.

Cheers!
Ulrike

Bug#924253: [Pkg-privacy-maintainers] Bug#924253: Bug#924253: mat2: Please update backport provided via stretch-backports

[Ulrike Uhlig]

Hi Georg,

On 16.04.19 13:15, Georg Faerber wrote:
> On 19-03-10 15:43:46, Georg Faerber wrote:
>> [...]
>>
>> Therefore, the current version of nautilus-python in testing, 1.2.2-2,
>> needs to be backported first. I've asked the maintainers to provide
>> such a backport, see #924250 for details.
> 
> It has been five weeks since my initial mail, and I've pinged the
> nautilus-python maintainers two more times in the meantime: some days
> ago via the BTS, and yesterday again via IRC -- no response, so far.
> 
> Any hints how to go forward with this? I don't want to step on anyone's
> toes, on the other hand, I'm a bit tired to wait (up until forever?).

I don't think there is a policy issue with uploading this backport
yourself (so no toe-stepping involved), but by uploading that backport
you commit to keep it alive during the lifetime of stretch-backports.

The question would rather be if there might be technical issues
resulting from that upload for users of packages that use nautilus-python.

Cheers!
u.

Bug#924660: tails-installer: Should not be part of Buster

[Ulrike Uhlig]

Package: tails-installer
Severity: serious

I'm opening this RC bug in order to prevent tails-installer from
migrating to testing.

The package has effectively no more use in Debian and derivatives (apart
from Tails) anymore, as Tails is now shipping USB images instead of ISO
images.

Cheers!
u.



signature.asc
Description: OpenPGP digital signature

Bug#922883: [Pkg-privacy-maintainers] Bug#922883: onionshare: new onionshare 2.0

[Ulrike Uhlig]

Hi Jonatan,

On 21.02.19 19:57, Jonatan Nyberg wrote:
> package: onionshare
> severity: normal
> 
> Dear Maintainer,
> 
> Please consider to upgrade to the current upstream version of onionshare
> (2.0).

It will happen.

Cheers!
u.

Bug#917633: Also blocks migration of tails-installer

[Ulrike Uhlig]

Hello!

this issue currently also blocks the migration of tails-installer,
shortly before the freeze.

Cheers!
u.

Bug#916889: [Pkg-privacy-maintainers] Bug#916889: onionshare: recommends torbrowser-launcher in contrib

[Ulrike Uhlig]

Hi John!

thank you for this report.

John Scott:
> Package: onionshare
> Severity: minor
> 
> The Policy Manual suggests that OnionShare shouldn't depend or
> recommend torbrowser-launcher unless as an alternative to tor
> because it's in main (assuming OnionShare 1.3+ works with that).

Onionshare 1.3 now comes with a bundled tor, that is the default option
for connecting to Tor.

So indeed, we can and should drop the recommends.

However, using TBB as onionshare's tor is an option using the GUI, so I
believe we could have it as a "suggests".

And tor itself should possibly be moved to "Recommends", if I follow my
own reasoning here. Because not necessarily needed by Onionshare to work.

What do you think?

Cheers,
Ulrike

Bug#917955: RFS: usbguard

[Ulrike Uhlig]

Done!

Sorry for taking such a long time :)

Bug#865368: marked as done (torsocks: procmail spawned by mpop in torsocks fails with "Operation not permitted")

[Ulrike Uhlig]

Dear Nick,

> I hadn't seen the section of the manpage with the working Tor
> example, though, many thanks for pointing me to that. I have tested
> it, and that solution works fine.

Great!

> I'm closing the bug report, as this method is just as reasonable as
> using torsocks, and is well documented (despite my failure to find
> it).

Thank you.

> I'm quite new to the debian bugtracker, hopefully I've done
> everything right, apologies if not.

Welcome then! You did everything perfectly correct, thank you.

Cheers,
Ulrike

Bug#849227: GUI ignores server stay-open checkbox state

[Ulrike Uhlig]

This is fixed in the current version of Onionshare (> 1.3).

Bug#915859: [Pkg-privacy-maintainers] Bug#915859: uses a fixed filename in /tmp

[Ulrike Uhlig]

Hi!

Salvatore Bonaccorso:

> So it will additionally allow potentially denial of service on
> multi-user systems. 
> 
> Not sure if the grave severity is warranted, though, will leave this
> discussion to you both :)

Ack, grave sounds a bit grave.

> For tracking the issue, I have requested a CVE from MITRE, which got
> assigned CVE-2018-19960.

Thank you.

I've asked upstream to fix it yesterday, and they did. So I'll upload a
newer version of onionshare a bit later this week (probably not today
though).

Cheers!
u.

Bug#895903: [torsocks] AAAA replies from Tor not handled

[Ulrike Uhlig]

This seems to be due to a limit in torsocks that has not yet been
resolved upstream: to resolve an IPv6 address, Tor must listen on the
IPv6 SocksPort and the request must be sent to this SocksPort. As far as
i understand it.

Bug#865368: torsocks: procmail spawned by mpop in torsocks fails with "Operation not permitted"

[Ulrike Uhlig]

Hi Nick,

does this still occur?

It could be a problem related to multiprocesses in which procmail does
"socket passing" and which torsocks might not handle well, or at all.

mpop seems to have examples working with Tor though:
https://www.mankier.com/1/mpop#Examples Have you contacted the authors
of this software to ask for advice?

Cheers!
u.

Bug#895903: [torsocks] AAAA replies from Tor not handled

[Ulrike Uhlig]

Hi,

thank you for this bug report. I confirm this behavior and thus I've
forwarded it to Tor's bugtracker.

Cheers
Ulrike

Bug#867967: Fwd: Re: Bug#867967: apt: The key(s) in the keyring are ignored. Not readable by user '_apt'.

[Ulrike Uhlig]

Hi Julian,

while you argue that the error message is clear, and that this is not a
bug, but a support request, I actually disagree with your assessment.

I think this _is_ a bug (and actually it has been filed here: #864640),
because this behavior is not caused by a user having modified something
themselves. It seems that this file might have been created by Synaptic,
and later the user switching back to using apt on the command line gets
this error, while apt itself does not require the existence of this file
(please correct me if I'm wrong.) So this would actually be a bug in
Synaptic or leftover code in apt that tries to access that file. (I am
just guessing the part about the leftover code, so if you know more
about that, let me know.)

It seems to me that Debian currently lacks a way to install packages
easily using a GUI. This means that people who are not super power users
have no easy way to handle their packages. Older manuals will tell them
to use Synaptic but then Synaptic is old and broken. This is why users
will fall back to using apt on the command line. I find this overall
situation a bit sad and I hope we could be a bit more helpful and
empathic whenever such things happen and, if we have the time, try to
refer the user to the information they are looking for.

Cheers & thanks for your work on apt :)
Ulrike

Bug#911771: IPv4: AttributeError: 'module' object has no attribute 'in_' = Missing version constraint on python-attr dependencies

[Ulrike Uhlig]

After some research, this is actually not due to python-twisted but to a
change in the API of python-attrs in 17.1.0
(http://www.attrs.org/en/stable/changelog.html).

But python-twisted from stretch-backports has no versioned dependency on
python-attrs > 17.1.0. Installing python-attrs from stretch-backports
fixes the issue.

#910056 seems to concern the same problem and possibly #911771 should be
merged with it.

Ulrike

Bug#911771: IPv4: AttributeError: 'module' object has no attribute 'in_'

[Ulrike Uhlig]

package: python-twisted
severity:  normal

Dear Maintainer,

when launching torbrowser-launcher, that relies on python-twisted, I get
the following error:

  File "/usr/bin/torbrowser-launcher", line 29, in 
import torbrowser_launcher
  File
"/usr/lib/python2.7/dist-packages/torbrowser_launcher/__init__.py", line
33, in 
from .common import Common, SHARE
  File "/usr/lib/python2.7/dist-packages/torbrowser_launcher/common.py",
line 55, in 
from twisted.internet import gtk2reactor
  File
"/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line
23, in 
from twisted.internet import _glibbase
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_glibbase.py",
line 20, in 
from twisted.internet import base, posixbase, selectreactor
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line
27, in 
from twisted.internet._resolver import (
  File "/usr/lib/python2.7/dist-packages/twisted/internet/_resolver.py",
line 25, in 
from twisted.internet.address import IPv4Address, IPv6Address
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py",
line 23, in 
class IPv4Address(object):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/address.py",
line 37, in IPv4Address
type = attr.ib(validator=attr.validators.in_(["TCP", "UDP"]))

I'm using 18.7.0-2~bpo9+1 and
python 2.7.13-2 (as the default on Stretch).

Cheers,
u.

Bug#911764: nautilus-wipe should confirm that it is cancelling the wipe process as soon as the user cancels

[Ulrike Uhlig]

Package: nautilus-wipe
Severity: wishlist

Dear Maintainer,

The current user flow for cancelling a Wipe Available Disk Space process
needs some UX love.

Current situation:

When using the "Wipe Available Disk Space" feature on a 4GB FAT
formatted drive, the process seemed to be taking to long so a user
cancelled, after which a confirmation dialog appears and "Cancel
operation" is pressed. When that happens, the confirmation dialog
disappears but the Wipe Available Disk Space dialog is still there,
unchanged, and seems like it's ignoring the cancel request for a period
of time close to a minute before a cryptic message finally appears to
confirm it was cancelled.

How should the software behave:

Ideally, this flow should change so that when a user confirms the
cancellation, the Wipe Available Disk Space dialog should change to
indicate that the cancellation is being processed. This can be as simple
as changing the "Wiping available disk space..." copy to "Cancelling..."
Instead of seeing a cryptic message when the cancellation kicks in, the
displayed cancellation confirmation should just say that the wipe was
cancelled.

This was reported here: https://labs.riseup.net/code/issues/16066

I have contacted the upstream author by email, as indicated here:
https://wipetools.tuxfamily.org/nautilus-wipe.html

Bug#745661: Weblate packaging → Salsa?

[Ulrike Uhlig]

Hi Martin!

I just realize right now that we've been in touch before concerning this
package… I guess none of us was interested enough in migrating the
existing packaging to Salsa.

At Tails we are still interested in seeing this packaged, but we have
not tried it ourselves (yet?).

However, we've made some progress on listing dependencies, see
https://labs.riseup.net/code/issues/10038

I still have a local copy of the packaging files dating back to 2015
which I could upload to Salsa.

Is anybody interested in this?

Cheers!
Ulrike

Bug#900270: libcryptui: Fails to display the signing key when the signing key has multiple subkeys

[Ulrike Uhlig]

Hi!

Simon McVittie:
> Control: tags -1 + patch
> Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=774611
> 
> On Fri, 17 Aug 2018 at 14:11:00 +0000, Ulrike Uhlig wrote:
> If you're pinging a bug like this, please keep the subject line that
> identifies which package and bug you're talking about: maintainers will
> often see these messages completely out-of-context, and having to look
> up a bug number before you can do anything is not a great incentive to
> work on a particular bug :-)

Ack! Thanks for pointing it out. This is not very intuitive from the
BTS' web interface.

>> Unfortunately upstream has not replied, but you might still be able to
>> cherry-pick the patches… is that something you'd consider?
> 
> Adding metadata that could help someone do that.

Thanks.

> The patches appear to be:
> https://gitlab.gnome.org/GNOME/libcryptui/commit/bdd2fd518bac805e379ab6b23cc450d257d524fa
> "daemon: Add a hack to find subkeys identities"
> and
> https://gitlab.gnome.org/GNOME/libcryptui/commit/6a4d4b83bd1d82bcc21bf66143fecd04f8e872a6
> "daemon: Fall back to displaying the key ID if the key is not found"
> 
> Can you confirm that applying those two patches is sufficient?

I confirm this.

> (I have not attempted to review them)

 As you can see on the upstream bug report, they've actually merged them
into master.

> Back in 2017, upstream did say:
>> This library is on its last legs, however
> 
> I believe seahorse is not very maintained upstream at the moment, so
> if it's important to you, it might be a good idea for someone with a
> visible history of contributions to talk to upstream GNOME developers
> (perhaps the GNOME release team or the desktop-devel mailing list, if
> the maintainer of libcryptui can't be contacted?) about the possibility
> of taking over maintenance.

This seems like a good idea. I'll ask the people who proposed the patches.

Cheers!
u.

Bug#900270: Ping

[Ulrike Uhlig]

ping ^

Unfortunately upstream has not replied, but you might still be able to
cherry-pick the patches… is that something you'd consider?

Cheers!
Ulrike

Bug#904917: Confirmation: happens on my machine too

[Ulrike Uhlig]

Hi!

This happens on my stretch system too.
Randomly. Here is what I have in the kernel log:

Aug  6 10:04:14 panpaniscus kernel: [63602.944141] traps:
gnome-shell[1438] general protection ip:7f7b0f36f95a sp:7ffc5cb45aa0
error:0 in libgobject-2.0.so.0.5000.3[7f7b0f33b000+52000]

Version of gnome-shell is 3.22.3-3

I don't have an NVIDIA graphics card.

lspci says:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)

Maybe it helps debug this further.
Much appreciated.

Cheers!
Ulrike

Bug#893308: Worksforme

[Ulrike Uhlig]

Hi Georg,

with 2.9.3 this works for me without the error you describe (tested on
stretch though).

Interestingly you seem to be using a newer version of python-twisted
(17.9.0-1) than me (16.6.0-2). This error might be due to this. Can you
still reproduce this and if yes with which version of python-twisted?

Cheers!
u.

Bug#890238: Cannot confirm

[Ulrike Uhlig]

Hi!

I'm currently using 2.9.3 and I cannot confirm this bug.
Can you update and tell us if it is still present?

Cheers!
u.

Bug#903977: ITP: sbws -- Simple Bandwidth Scanner

[Ulrike Uhlig]

Hello!

Philipp Kern:
> On 18.07.2018 20:38, ju xor wrote:
>> Philipp Kern:
>>> On 2018-07-18 18:24, ju xor wrote:
 Philipp Kern:

> Should this live in some kind of tor-* namespace?
 no
>>> Without any rationale? :(
>> i'm not sure what you mean, but in case it helps, here some arguments
>> why sbws package is not called something like tor-sbws:

>> - upstream is not using "tor-*" in the name
>> - i don't think there's a Debian policy to name packages as "tor-*" [0]
> 
> Of course there isn't. But if the package is incredibly specialized, it
> might make sense to do that anyhow. Debian is not bound to reuse the
> upstream name, although in many cases it makes sense (first and foremost
> when scripts are concerned, but there are plenty of other reasons).

While that would be a good idea, I believe that software using "tor" in
their name needs to be acknowledged by the Torproject, see
https://www.torproject.org/docs/trademark-faq.html

We've however seen from previous experience that software not made by
the the Torproject is kindly requested to be named differently, hence
for example Tails' previously called tor-monitor software has been
renamed to "onioncircuits".

>> - nyx, is a tor monitor, and is not called "tor-*"
> 
> Fair. Although, to note, it used to be called tor-arm according to the
> package's description. And it feels like the possible target audience of
> sbws is even less than the one of nyx. That said: Maybe include the
> target audience (i.e. who is going to have an interest in running this
> package) somewhere in your description. If this is of interest to all
> relay operators rather than just the authorities, that's probably relevant.

I don't know what this name change was motivated by.

>> - there're several packages called "onion*", which is not "tor-*"
> 
> Well, tor-* was a proposal to disambiguate a short name. I don't
> particularly care what the prefix would be.

See above. If anything, the package could use the `onion` prefix in
Debian, but as this is not policy and IMO even adds more complexity, it
could also simply use the upstream name as initially suggested by Ju.

Cheers!
Ulrike

Bug#900270: Fails to display the signing key when the signing key has multiple subkeys

[Ulrike Uhlig]

Package: libcryptui
Severity: normal

Hi!

Seahorse relies on libcryptui to display a signature after file
verification. However, this is broken when the signing key has multiple
subkeys. This was reported upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=774611 and a patch was merged
into master / libcryptui 3.20.

I think this behavior results in a UX issue, which makes it impossible
for users using a GUI to be sure that a file is verified.

It would be nice to cherry-pick those patches in Debian. This would not
only allow Tails users to make use of this feature (That's where this
request an patches are originating from, see
https://labs.riseup.net/code/issues/11946).

I've also opened an issue to ask for a new upstream release as 3.12
dates back to 2014: https://gitlab.gnome.org/GNOME/libcryptui/issues/1

Cheers!
Ulrike

Bug#855016: Onionshare 1.3 implements possibility to use system tor

[Ulrike Uhlig]

Onionshare 1.3 ships a bundled Tor and allows also to use system tor or
TBB's tor. When wanting to use system tor, you

- need to be in the debian-tor group
- open tor's control port

Also see https://github.com/micahflee/onionshare/wiki/Connecting-to-Tor
for more information.

I think we can now close this wishlist bug.

Bug#861239: Impossible to connect to SFTP servers

[Ulrike Uhlig]

Hello Noël,

Noël Köthe:
> Am Mittwoch, den 26.04.2017, 12:21 + schrieb Ulrike Uhlig:

thanks a lot for the quick answer!

>> I'm trying to connect to a SFTP server on port 22 using lftp.
>> The same connection works fine from a GUI client.

[..]

> It is compiled against GNUTLS. 

Correct.

> You can test it with:
> 
> # lftp -d https://www.debian.org/
> and see the certificate for example.
> What is the debug output of your SFTP connection?

Here is what I'm doing:

lftp -d user:p...@sftp.dc0.gpaas.net -p 22
 Löse Hostadresse auf...
 2  Adressen gefunden: 2001:4b98:dc0:950::142, 217.70.180.142

lftp u...@sftp.dc0.gpaas.net:~> ls
 Verbinde mit sftp.dc0.gpaas.net (2001:4b98:dc0:950::142) Port 22
<--- SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
»ls« bei 0 [TLS Verbindungsaufbau...]

And it gets stuck at "ls". Nothing happens, no debugging information. No
certificate, no fingerprint.

I'm using lftp 4.6.0-1+deb8u1.

This also happens when I use one of the IPs directly. I tried that
because I suspected that there might be something wrong with the IPv6
address.

Cheers,
Ulrike

Bug#861239: Impossible to connect to SFTP servers

[Ulrike Uhlig]

Package: lftp
Severity: normal

Hi,

I'm trying to connect to a SFTP server on port 22 using lftp.
The same connection works fine from a GUI client.

It never works out, and I was wondering if this might be due to lftp not
being compiled with libssl?

Here's what I get with ldd:

ldd /usr/bin/lftp
linux-vdso.so.1 (0x7fffa9db5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fcb63448000)
libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28
(0x7fcb63129000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
(0x7fcb62edf000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7fcb62cdc000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 
(0x7fcb62ab2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fcb628ae000)
libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 
(0x7fcb6267a000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x7fcb6236f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fcb6206e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7fcb61e58000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fcb61aad000)
libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
(0x7fcb61867000)
libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
(0x7fcb61653000)
libnettle.so.4 => /usr/lib/x86_64-linux-gnu/libnettle.so.4
(0x7fcb61421000)
libhogweed.so.2 => /usr/lib/x86_64-linux-gnu/libhogweed.so.2
(0x7fcb611f2000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 
(0x7fcb60f6f000)
/lib64/ld-linux-x86-64.so.2 (0x7fcb63663000)
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 
(0x7fcb60d67000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fcb60b4a000)

This makes lftp kinda unusable for connection to SFTP servers.
Or am I missing something here?

Cheers!
u.

Bug#858034: [Pkg-privacy-maintainers] Bug#858034: Deleting patches

[Ulrike Uhlig]

Hi,

Right, it would not work out of the box without the dependency.

I agree with you that there should be a long term solution such as
creating a vendor specific file. However, right now I have not enough
time to test that in detail and I want to bring out the new upstream
version nevertheless.

So I'll do that for now, leave this bug open and will get back to it later.

Cheers!
u.

Bug#858034: Deleting patches

[Ulrike Uhlig]

Hi!

thanks for pointing this out. Indeed, these (old) patches are actually
not even needed. I've decided to delete them from the packaging. This
will result in
* new users will use the default TorBirdy configuration, which uses port
9150, or TorBrowser's tor.
* every user is able to modify TorBirdy's preferences to use system
tor's port, 9050
* users who have already modified these preferences in the past are not
affected by this change, as settings persist, even after an upgrade from
0.2.1 to 0.2.2. I've tested this on my own, Jessie system.

This should in no way interfere with the way Tails handles this.
What do you think?

Cheers!
u.

Bug#858174: Please provide an AppArmor profile for Firefox

[Ulrike Uhlig]

Hi Mike,

Mike Hommey:
> control: reassign -1 apparmor-profiles
>> Package: firefox
>> Severity: normal

>> as you might know, AppArmor confines programs according to a set of
>> rules that specify what files a given program can access. This approach
>> helps protect the system against both known and unknown vulnerabilities.
>> In several distributions such as Ubuntu or Tails, AppArmor is enabled by
>> default.
> 
> AppArmor profiles ought to be in the apparmor-profiles package. In fact,
> there is one for Firefox there according to
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805594#24

@intrigeri: I was not aware that this profile is considered incomplete.
Ubuntu ships it in Firefox as it seems. Or did I misunderstand that?

> If it needs update, this should happen there.

The ultimate aim for AppArmor in Debian is to have each package install
their own profile an make the apparmor-profiles and
apparmor-profiles-extra package disappear on the long term.

Cheers!
u.

Bug#858174: Please provide an AppArmor profile for Firefox

[Ulrike Uhlig]

Package: firefox
Severity: normal

Hi,

as you might know, AppArmor confines programs according to a set of
rules that specify what files a given program can access. This approach
helps protect the system against both known and unknown vulnerabilities.
In several distributions such as Ubuntu or Tails, AppArmor is enabled by
default.

I've not been able to find such a profile in the current Firefox package.

There is an AppArmor profile for Firefox available upstream:
https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/firefox/vivid/view/head:/debian/usr.bin.firefox.apparmor.10.04
(this is the upstream profile which has been integrated into Ubuntu's
packaging of Firefox).

This profile is only active if people have installed AppArmor in first
case, so it should never break the package for users without AppArmor.

The profile can be included in your packaging quite easily.
All the necessary steps are documented here:
https://wiki.debian.org/AppArmor/Contribute/FirstTimeProfileImport

Please also see examples in the packages torbrowser-launcher or in
Icedove
(https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/tree/debian).

Please let me know if you need help.

Cheers!
ulrike

Bug#853929: (no subject)

[Ulrike Uhlig]

Proposed Douglas' patch here:

https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+ref/thunderbird/links

Bug#853929: Please upstream modifications to Thunderbird/Icedove AppArmor profile

[Ulrike Uhlig]

Hi Douglas,

>> it's great that you provided modifications to the AppArmor profile in
>> Debian! May I kindly ask you to send these upstream too? 

>> If you think that's too much work, please just tag your bug using a
>> usertag. The corresponding tag would be "merge-to-upstream" and then the
>> AppArmor team can take care of this. See
>> https://wiki.debian.org/AppArmor/Reportbug#Usertags for how to do that.
> 
> Thanks. I am taking this last option because trying to work out where
> that commit with the dots-for-spaces came from has baffled me, and in
> dealing with upstream I lack the historical context of the two teams
> interactions to know whether they would prefer the broken patch and
> its fix merged into one or both in series or some other thing. People
> are particular about how they like to manage mistakes in their git
> trees, so it is best in this case that you/they do it.

I've just updated the documentation:
https://wiki.debian.org/AppArmor/Contribute/Upstream#Quick_howto_contribute_to_upstream_AppArmor_profiles_using_Git
because I realized that some parts were missing. Basically the idea
would always be to get patches upstreamed and then to tell Debian
(Thunderbird +  AppArmor) maintainers about it once it's been merged.

For this particular case, I think Simon said he would take care of it.

Have a nice day,
ulrike

Bug#855346: Upstream pull request

[Ulrike Uhlig]

Control: forwarded 855346
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276

I've proposed a change upstream here:
https://code.launchpad.net/~u-d/apparmor-profiles/+git/apparmor-profiles/+merge/320276


Cheers,
ulrike

Bug#855346: Reopening

[Ulrike Uhlig]

Control: reopen 855346

Hi Carsten,

I think you meant to close 855343 instead.

I can still reproduce this problem with the latest profile from the
Debian archive. I'll look into it.

Cheers!
u.

Bug#853929: Upstreaming & Documenting

[Ulrike Uhlig]

Hi!

>> And, would you or someone else with the apparmor background create a
>> sentence about the Apparmor profile in Thunderbird within the new
>> Thunderbird wiki site?
> 
>> https://wiki.debian.org/Thunderbird

That was done here: https://wiki.debian.org/Thunderbird#AppArmor_profile
please don't hesitate to review it.

I thinkit's best to simply forward these bugs upstream or usertag them
for the AppArmor team and then we'll forward them upstream if you don't
feel like handling it.

Cheers & thanks for your work on Icedove!
u.

Bug#853929: Please upstream modifications to Thunderbird/Icedove AppArmor profile

[Ulrike Uhlig]

Hi Douglas,

it's great that you provided modifications to the AppArmor profile in
Debian [1]! May I kindly ask you to send these upstream too? That way,
they will get reviewed first and then all other distributions using
AppArmor can profit from your improvements.

Debian has some documentation on how to do so:
https://wiki.debian.org/AppArmor/Contribute/Upstream

Basically, their Git repo lives here:
https://code.launchpad.net/~apparmor-dev/apparmor-profiles/+git/apparmor-profiles
(The particular file lives here:
https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.04/usr.bin.thunderbird)
When done, you can ask for a merge using Launchpad or the mailinglist:
appar...@lists.ubuntu.com

If you think that's too much work, please just tag your bug using a
usertag. The corresponding tag would be "merge-to-upstream" and then the
AppArmor team can take care of this. See
https://wiki.debian.org/AppArmor/Reportbug#Usertags for how to do that.

Thank you!
ulrike

[1]
https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/commit/?h=debian/experimental=e2c8a2391c7b6d422f5df40682b8b19f08b88dcf

Bug#853929: Upstreaming & Documenting

[Ulrike Uhlig]

Hi Carsten,

oh, sorry! For some reason I did not receive this email, or accidentally
deleted it. So answering only now...

> @Ulrike
> Would you point this issue upstream? Need we a also a update for the
> profile of Thunderbird in Debian? If so could you provide a patch?

I'll take care of it (instead of asking Douglas to do so.), sure.

> And, would you or someone else with the apparmor background create a
> sentence about the Apparmor profile in Thunderbird within the new
> Thunderbird wiki site?

> https://wiki.debian.org/Thunderbird

I will do that.

Cheers!
ulrike

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Ulrike Uhlig]

Hi Felipe,

>>> + # install apparmor profile
>>> + cp debian/apparmor/usr.bin.pulseaudio
>>> debian/pulseaudio/etc/apparmor.d/usr.bin.pulseaudio
>>>
>>> This would install the file with whatever umask is currently set.
>>
>> Thanks for making this clear.
>> Yes. root:root 644 is correct.
> 
> Thanks. I have changed this to install -m 644 instead of cp.

Perfect.

> BTW, I still would like an answer to this question:
> 
> Wouldn't that benefit be best achieved if the profile was shipped
> by (pulse) upstream?
> 
> AFAICT, this file should be distro-agnostic, so it should be safe to
> ship in the upstream package, wouldn't it?

The apparmor profile itself could indeed be part of the upstream package.

Currently, these profiles are worked on collectively by people from
Ubuntu, Debian/Tails and OpenSuSe and we use a shared Git repository
between our three distributions.

For torbrowser-launcher we upstreamed the profile for example, also
because upstream is very responsive about patches. But I have no other
examples in mind where this would be the case.

Would you care to ask upstream if they'd like to include it?

Cheers!
ulrike

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Ulrike Uhlig]

Control: tags + patch

Hi!

Felipe Sateler:
> On Wed, Mar 15, 2017 at 11:23 AM, Ulrike Uhlig <ulr...@debian.org> wrote:
>> tags + patch
>>
>> Hi,
>>
>>>> I'll try to prepare a patch to make it easier for you to integrate it.
>>>
>>> That would be great.
>>
>> Please find a patch attached.
> 
> Thanks.
> 
>>
>> The will simply to copy the file to /etc/apparmor.d/ and only if the
>> user has AppArmor installed and enabled, this will then confine the
>> pulseaudio executable. Furthremore, dh_apparmor should create an empty
>> file /etc/apparmor.d/local/usr.bin.pulseaudio which can be used for
>> local overrides.
> 
> 
> + # install apparmor profile
> + cp debian/apparmor/usr.bin.pulseaudio
> debian/pulseaudio/etc/apparmor.d/usr.bin.pulseaudio
> 
> This would install the file with whatever umask is currently set.

Thanks for making this clear.

> Which permissions should the file have? root:root 644 ?

Yes. root:root 644 is correct.

Cheers!
u.

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Ulrike Uhlig]

tags + patch

Hi,

>> I'll try to prepare a patch to make it easier for you to integrate it.
> 
> That would be great.

Please find a patch attached.

The will simply to copy the file to /etc/apparmor.d/ and only if the
user has AppArmor installed and enabled, this will then confine the
pulseaudio executable. Furthremore, dh_apparmor should create an empty
file /etc/apparmor.d/local/usr.bin.pulseaudio which can be used for
local overrides.

FYI I've not tried to build the package with this modification.

Let me know if it works out :)

Cheers!
ulrike
diff --git a/apparmor/usr.bin.pulseaudio b/apparmor/usr.bin.pulseaudio
new file mode 100644
index 000..23113ac
--- /dev/null
+++ b/apparmor/usr.bin.pulseaudio
@@ -0,0 +1,117 @@
+# Origin: https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.04/usr.bin.pulseaudio
+# Last commit: b0d658f9caba715e54b6efd41e298fd9d4511bd9
+#include 
+
+/usr/bin/pulseaudio {
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+  #include 
+
+  dbus send
+   bus=system
+   path=/org/freedesktop/RealtimeKit1
+   interface=org.freedesktop.RealtimeKit1
+   member={MakeThreadRealtime,MakeThreadHighPriority}
+   peer=(name=org.freedesktop.RealtimeKit1),
+
+  dbus send
+   bus=system
+   path=/org/freedesktop/RealtimeKit1
+   interface=org.freedesktop.DBus.Properties
+   member=Get,
+
+  unix (connect, receive, send) type=stream peer=(addr="@/tmp/.ICE-unix/[0-9]*"),
+  ptrace (read,trace) peer=@{profile_name},
+
+  /usr/bin/pulseaudio mixr,
+
+  /etc/pulse/ r,
+  /etc/pulse/* r,
+  /etc/udev/udev.conf r,
+  /etc/timidity/.pulse_cookie w,
+
+  owner @{HOME}/.esd_auth rwk,
+  owner @{HOME}/.pulse-cookie rwk,
+  owner @{HOME}/.config/pulse/cookie rwk,
+  owner @{HOME}/{.config/pulse,.pulse}/ rw,
+  owner @{HOME}/{.config/pulse,.pulse}/* rw,
+
+  owner /run/pulse/ rw,
+  owner /run/pulse/.pulse-cookie rwk,
+  owner /run/pulse/dbus-socket rwk,
+  owner /run/pulse/native rwk,
+  owner /run/pulse/pid rwk,
+  owner /run/user/[0-9]*/pulse/  rw,
+  owner /run/user/[0-9]*/pulse/* rwk,
+  /run/udev/data/+sound:card* r,
+  /run/udev/data/c116:[0-9]* r,
+  /run/udev/data/c14:[0-9]* r,
+
+  # logind
+  /run/systemd/users/[0-9]* r,
+  /run/user/[0-9]*/dconf/user k,
+
+  /sys/bus/ r,
+  /sys/class/ r,
+  /sys/class/sound/ r,
+  /sys/devices/pci[0-9]*/**/*class r,
+  /sys/devices/pci[0-9]*/**/uevent r,
+  /sys/devices/system/cpu/ r,
+  /sys/devices/system/cpu/online r,
+  /sys/devices/virtual/dmi/id/bios_vendor r,
+  /sys/devices/virtual/dmi/id/board_vendor r,
+  /sys/devices/virtual/dmi/id/sys_vendor r,
+  /sys/devices/virtual/sound/**/uevent r,
+
+  /usr/share/alsa/** r,
+  /usr/share/applications/ r,
+  /usr/share/applications/* r,
+  /usr/share/pulseaudio/** r,
+  /usr/lib/pulse-[1-9]*.[0-9]/modules/*.so mr,
+  /usr/lib/pulseaudio/pulse/gconf-helper Cx,
+
+  owner /var/lib/gdm3/.config/pulse/ rw,
+  owner /var/lib/gdm3/.config/pulse/* rw,
+  owner /var/lib/gdm3/.config/pulse/cookie rwk,
+
+  owner /var/lib/lightdm/.Xauthority r,
+  owner /var/lib/lightdm/.esd_auth rwk,
+  owner /var/lib/lightdm/.config/pulse/cookie rwk,
+  owner /var/lib/lightdm/.config/pulse/ rw,
+  owner /var/lib/lightdm/.config/pulse/* rw,
+
+  # are these needed?
+  /var/lib/pulse/ rw,
+  /var/lib/pulse/*-default-sink rw,
+  /var/lib/pulse/*-default-source rw,
+  /var/lib/pulse/*.tdb rw,
+
+  owner @{PROC}/@{pid}/fd/ r,
+  owner @{PROC}/@{pid}/maps r,
+  owner @{PROC}/@{pid}/stat r,
+
+  owner /tmp/pulse-*/pid rwk,
+  owner /tmp/pulse-*/native rwk,
+  owner /tmp/pulse-*/autospawn.lock rwk,
+  owner /run/user/*/pulse/autospawn.lock rwk,
+
+  owner /tmp/orcexec.* mrw,
+  owner /{,var/}run/user/[0-9]*/orcexec.* mrw,
+  # needed if /tmp is mounted noexec:
+  owner @{HOME}/orcexec.* mrw,
+
+  owner /tmp/.esd-@{pid}*/ rw,
+  owner /tmp/.esd-@{pid}*/socket rw,
+
+  profile /usr/lib/pulseaudio/pulse/gconf-helper {
+#include 
+
+/usr/lib/pulseaudio/pulse/gconf-helper mr,
+  }
+
+  # Site-specific additions and overrides. See local/README for details.
+  #include 
+}
diff --git a/debian/rules b/debian/rules
index a16fea9..350fd5a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -60,6 +60,9 @@ override_dh_shlibdeps:
 
 override_dh_install:
 	dh_install --fail-missing
+	# install apparmor profile
+	cp debian/apparmor/usr.bin.pulseaudio debian/pulseaudio/etc/apparmor.d/usr.bin.pulseaudio
+	dh_apparmor --profile-name=usr.bin.pulseaudio -ppulseaudio
 
 override_dh_installdocs:
 	dh_installdocs -A NEWS README AGPL

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Ulrike Uhlig]

Hi Felipe,

thank you for your answer.

Felipe Sateler:
> On Wed, Mar 15, 2017 at 5:07 AM, Ulrike Uhlig <ulr...@debian.org> wrote:
>> Package: pulseaudio

> I have some doubts:
> 
> 1. What is the benefit of shipping the profile info in pulseaudio
> versus shipping it in the apparmor-profiles package?

The ultimate aim of the Debian AppArmor team is to have all profiles
shipped in their respective packages. Why? Because the package
maintainers are the ones who know how their package should work and they
are ideally placed to see when something is wrong.

This is also what Ubuntu is doing by the way. They have enabled AppArmor
by default since years to provide users with Mandatory Access Control.

Furthermore, the apparmor-profiles-extra package is supposed to disappear.

> 2. Wouldn't that benefit be best achieved if the profile was shipped
> by (pulse) upstream?

> I'm wary of being in charge of stuff I don't use, and I would think

You should use this kind of stuff ;)
It's super easy to setup see https://wiki.debian.org/AppArmor/HowToUse

> upstream would be as well. Would apparmor maintainers be willing to
> step in to help when problems appear with the profile?

Absolutely. To help you here, we (the AppArmor team) have set up this
documentation: https://wiki.debian.org/AppArmor/Debug If ever people
report bugs against Pulseaudio related to AppArmor, you can invoke help
by the AppArmor team by usertagging such bugs so they will appear on our
radar.

Furthermore, the upstream authors are very responsive, and I'm convinced
they react quickly. FYI upstream can be contacted through
appar...@lists.ubuntu.com

>> I'll try to prepare a patch to make it easier for you to integrate it.
> That would be great.

Ack.

Cheers!
ulrike

Bug#857798: Please add an AppArmor profile for Pulseaudio

[Ulrike Uhlig]

Package: pulseaudio
Severity: normal

Hi,

as you might know, AppArmor confines programs according to a set of
rules that specify what files a given program can access. This approach
helps protect the system against both known and unknown vulnerabilities.
In several distributions such as Ubuntu or Tails, AppArmor is enabled by
default.

There is an AppArmor profile for Pulseaudio available upstream:
https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.04/usr.bin.pulseaudio
I've asked the original authors if this profile is ready to be included
and they confirmed. In any case, this profile is only active if people
have installed AppArmor in first case, so it should never break the
package for users without AppArmor.

The profile can be included in the Pulseaudio packaging quite easily.
All the necessary steps are documented here:
https://wiki.debian.org/AppArmor/Contribute/FirstTimeProfileImport

Please also see examples in the packages torbrowser-launcher or in
Icedove
(https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git/tree/debian).

I'll try to prepare a patch to make it easier for you to integrate it.

Cheers!
u.