tls protect
Debian users against exploitation, so I find RC severity hard to
justify given this only affects users who manually pass --debug under
a non-default sysctl/kernel configuration.
In any case, this should be fixed :)
Cheers,
--
intrigeri
Niko Tyni:
> It looks like 0.56-2 relies on the Perl 5.26 ExtUtils::MakeMaker behaviour
> of erroneously installing README.pod. This was introduced just a few
> days before 5.28 was uploaded to sid, so we missed it in our 5.28
> test rebuilds.
Good catch, thanks! Do you plan to fix this bug or sho
I should add that I'm not running away because maintaining metche is
particularly troublesome: it is pretty stable software, does its
intended job pretty well, hasn't bitrotted, and does not require much
maintenance work (maybe 4-12 hours a year).
I'm simply cleaning up my plate of things I don't
the keys :)
Unless upstream and package maintenance are taken over by July 2019,
I'll orphan the package or request it to be removed from sid (I'm
undecided yet, opinions welcome).
Cheers,
--
intrigeri
Jonas Smedegaard:
> Please drop it. Thanks!
Thanks for the quick reply! Filed #912830.
Cheers,
--
intrigeri
Hi,
as announced in July, I've requested the removal of this package from
sid: #912744
Cheers,
--
intrigeri
ose we remove it
from the archive; happy to deal with the paperwork myself (except
moving to "attic" or whatever it's called in the Salsa days, which
I've consistently forgotten).
Cheers,
--
intrigeri
Hi,
as announced in July, I've requested this package to be removed from
sid: https://bugs.debian.org/912743
Cheers,
--
intrigeri
Osamu Aoki:
> On Sat, Jun 30, 2018 at 12:06:18PM +0200, intrigeri wrote:
>> Hi,
>>
>> do you plan to fix #899958 and #899538 soon? I could not find updates
>> nor any Git repo on Salsa.
Thanks for fixing these! Glad to see these two packages back in
testing :)
isted in the Uploaders
+field who did most of the recent uploads: the team mailing list
+is deprecated (Closes: #899616).
+
+ -- intrigeri Tue, 30 Oct 2018 18:33:51 +
+
myspell-fa (0.20070816-3) unstable; urgency=low
* Switch to dpkg-source 3.0 (quilt) format
diff -Nru myspe
st of the recent uploads: the team mailing list
+is deprecated (Closes: #899539).
+
+ -- intrigeri Tue, 30 Oct 2018 18:31:07 +
+
hunspell-ar (3.2-1) unstable; urgency=low
* New upstream release
diff -Nru hunspell-ar-3.2/debian/control hunspell-ar-3.2/debian/control
--- hunspell-a
Control: severity -1 normal
intrigeri:
> Due to this bug, merely installing the surf package on a default
> Debian testing/sid system breaks unrelated functionality, which is RC
> ⇒ bumping severity.
I was wrong: failure to load one AppArmor profile only affects this
profile, but the re
intrigeri:
> s/Apparmor/AppArmor/ :)
There was another similar typo, attached patch fixes both.
Cheers,
--
intrigeri
>From 97cbdd10a4f9af31d78136a1f1c76f2a4126b806 Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Sat, 27 Oct 2018 09:34:33 +
Subject: [PATCH 2/3] Fix spelling of &qu
5.
Cheers,
--
intrigeri
NMU earlier after testing the
proposed command line. Bonus points if you submit the changes in your
upload as a merge request against
https://salsa.debian.org/apparmor-team/apparmor :)
Cheers,
--
intrigeri
Hi Georg,
Georg Faerber:
> Currently, we don't ship the logo, but I'm unsure if this matters?
We do ship the logo in the source package so it does matter :)
Cheers,
--
intrigeri
package.
To reproduce, I think you need 1. adequate installed;
2. upgrading from a specific version of the package.
Cheers,
--
intrigeri
is not allowed to start
any "Web Content" process.
Cheers,
--
intrigeri
I have a fix ready somewhere, not sure I've pushed this to the
upstream Git repo yet. I'll try to fix that upstream by the end of
the week.
Elana Hashman:
> This is ready to migrate down to testing now.
Great news!
> I was waiting for two things:
> - ensure 1.9 and 1.8 can be simultaneously installed (required fixing
> the alternatives logic)
> - piuparts tests actually passed
> These are both fixed so let us loose 1.9 on the wor
Randy Stauner:
> I am the most recent releaser, but I do not have time to work on this (or
> anything perl, sadly) any more.
Thanks for letting us know!
Package: libgtk2-gladexml-perl
Version: 1.007-2
Severity: serious
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has only 4 reverse-dependencies, 3 of which are unlikely
to be part of Buster anyway:
- libgtk2-gladexml-simple-perl: filed #904551 to avoid shipping it in Bu
Related: this package depends on libgtk2-gladexml-perl, which I'd
rather not include in Buster (I'll probably file a RC bug to this end
once I'm done with the reverse-dependency analysis).
Package: libgtk2-trayicon-perl
Version: 0.06-2
Severity: serious
GTK+ 2 has been deprecated upstream for years. Let's ship as little
Perl GTK+ 2 bindings as we can in Buster.
This package has only one reverse-dependency in the archive
(checkgmail), which is orphaned and dead upstream. I'll file a
Package: libgtk2-traymanager-perl
Version: 0.05-3+b4
Severity: serious
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-spell-perl
Severity: serious
Version: 1.04-3
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-notify-perl
Severity: serious
Version: 0.05-5
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-ex-volumebutton-perl
Severity: serious
Version: 0.07-3
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-ex-simple-list-perl
Severity: serious
Version: 0.50-3
Let's ship as little GTK+ 2 binding as we can in Buster.
This package has only one reverse-dependency in the archive
(libgtk2-ex-podviewer-perl) for which I've filed a RC bug too.
Package: libgtk2-gladexml-simple-perl
Version: 0.32-3
Severity: serious
Let's ship as little GTK+ 2 bindings as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-ex-printdialog-perl
Severity: serious
Version: 0.03-4
Let's ship as little GTK+ 2 binding as we can in Buster.
This package has no reverse-dependency in the archive.
Package: libgtk2-ex-podviewer-perl
Severity: serious
Version: 0.18-2
Let's ship as little GTK+ 2 binding as we can in Buster.
This package has no reverse-dependency in the archive.
Cheers,
--
intrigeri
he package from Debian
around the end of August. This of course does not affect the standing
of your module on CPAN.
Thank you for maintaining this module so far!
Cheers,
--
intrigeri
Package: libgtk2-ex-entry-pango-perl
Severity: serious
Version: 0.10-1
Control: block -1 by 885675
User: pkg-perl-maintain...@lists.alioth.debian.org
Usertags: gnome2-removal
Yet another {GNOME,GTK+} 2 cleanup bug for Buster.
Its only reverse-dependency is xacobeo, see #885675.
Requested removal: #904534
Control: block -1 by 904535
Requested removal.
Requested removal: #904531
intrigeri:
> OK. I'll file the removal requests today.
That's #904526.
moval requests today.
Cheers,
--
intrigeri
don't hear anything we will remove the package from Debian
around the end of August. This of course does not affect the standing
of your module on CPAN.
Thank you for maintaining this module so far!
--
intrigeri
remove the package from Debian
around the end of August. This of course does not affect the standing
of your module on CPAN.
Thank you for maintaining this module so far!
--
intrigeri
7;t hear anything we will remove the package from Debian
around the end of August. This of course does not affect the standing
of your module on CPAN.
Thank you for maintaining this module so far!
--
intrigeri
remove the package from Debian in ~1
month. This of course does not affect the standing of your module
on CPAN.
Thank you for maintaining this module so far!
--
intrigeri
Package: libdevel-beginlift-perl
Severity: serious
Version: 0.001003-1
Running Mkbootstrap for BeginLift ()
chmod 644 "BeginLift.bs"
"/usr/bin/perl" "-Iinc" -MExtUtils::Command::MM -e 'cp_nonempty' --
BeginLift.bs blib/arch/auto/Devel/BeginLift/BeginLift.bs 644
"/usr/bin/perl" "-Iinc" "/usr/shar
to bring a new Shutter
version that does not depend on these obsolete libraries. Dominique,
what do you think?
Jeremy, what's the plan wrt. obsolete GNOME libraries in sid?
Cheers,
--
intrigeri
, which
is why these problems appeared on my radar.
If you lack time to take care of it yourself soon, I can offer to NMU
these packages in order to set the maintainer address to person listed
in the Uploaders field who did most of the recent uploads. Just let me
know :)
Cheers,
--
intrigeri
migrate back into
testing, until your team has had time to find out how you want to fix
this. Just let me know :)
Cheers,
--
intrigeri
FWIW it's unlikely that I have time to work on this myself before
DebCamp *but* if they've not been solved by then, fixing these
regressions will be one of my top priorities at DebCamp (ideally with
someone else).
?
Cheers,
--
intrigeri
on another bug report that
I could not find?
Cheers,
--
intrigeri
Damyan Ivanov:
> -=| gregor herrmann, 18.05.2018 11:09:23 +0200 |=-
>> So I guess we have to consider if we're happy with the ability to
>> turn off loading objects and recommend it to consumers and close the
>> bugs; or if we want to change the defaults, which means setting
>> $YAML::LoadBlessed t
7;s OK to interactively prompt the user during upgrades)
finally: unload the old profile
This should fix the two failure modes I've described above.
I'll let the active package maintainers make the call. I'm happy to
provide more info if needed :)
Cheers,
--
intrigeri
0.2.9-2~ for the first time and if so, display the same
recommendation (in a non-interactive way). But let's not block on
that :)
Cheers,
--
intrigeri
lure happens when our replacement for the load method calls the
original one:
https://salsa.debian.org/ruby-team/ruby-rjb/blob/master/debian/patches/0005-Fill-JAVA_HOME-with-a-sensible-value-if-not-set-when.patch
But dropping that patch does not change anything.
Cheers,
--
intrigeri
as part of the
pkg-privacy team or outside :)
Cheers,
--
intrigeri
Adrian Bunk:
> Alternatively, I can fix it for stretch if you don't object.
Yes, please :)
Cheers,
--
intrigeri
Control: tag -1 + patch
intrigeri:
>> B) remove the AppArmor profile entirely and rely on seccomp instead
>> C) don't enable "no new privs" and rely on AppArmor instead
> I think B is fine given all the non-AppArmor hardening efforts Colin
> has been putting i
intrigeri:
> A) drop the child profiles (groff, filter), merge their rules into the
>main /usr/bin/man profile, and use ix instead of Cx; these rules
>are not particularly scary so this doesn't seem crazy an option
I had a closer look and what's scary is not the rules t
ed on
top of that, didn't check recently, sorry). Marking/disabling
apparmor.service merely prevents policy loading on boot and might not
be what you want.
Cheers,
--
intrigeri
seem crazy an option
B) remove the AppArmor profile entirely and rely on seccomp instead
C) don't enable "no new privs" and rely on AppArmor instead
Personally my choice would be A >> B >> C.
Colin, if you need help with option A, please let us know :)
Cheers,
--
intrigeri
in Debian Stretch.
Cheers,
--
intrigeri
Hi,
Joachim Breitner:
> yarssr is dead upstream (for a decade or so) and I’d rather drop it
> than patch it. So when it is time to RM gnome-vfs, feel free to RM
> yarssr as well.
Thanks! I've requested the removal today: #885911.
#x27;t know how to
fix this, and IMO we should not block on it before we address the bug
I'm reporting here, but perhaps it's worth a NEWS.Debian entry?
Cheers,
--
intrigeri
Jan Luca Naumann:
> I have already prepared an upload but there was a seg fault on my test
> system I want to investigate before uploading.
Great, thanks for the update!
x27;s 2.11.1).
> I also can't see it being overridden anywhere. So I am not sure why this
> permission should be denied...
Can you please share the content of your
/etc/apparmor.d/abstractions/python file?
Cheers,
--
intrigeri
ity of cases. Besides, I would feel wrong
to see live-boot automatically removed from testing merely because of
this bug. So perhaps this could be demoted to severity:important?
Cheers,
--
intrigeri
actical or not feasible) so that we're
> ready when 4.14 reaches sid?
Linux 4.14 is now in sid so I think this makes this bug RC.
Cheers,
--
intrigeri
quot;obfsproxy" requested_mask="c"
denied_mask="c" fsuid=1002 ouid=1002
Nov 21 18:45:11 ensifera kernel: audit: type=1400 audit(1511286311.333:1879):
apparmor="DENIED" operation="open" profile="/usr/bin/obfsproxy"
name="/proc/6975/mounts" pid=6975 comm="obfsproxy" requested_mask="r"
denied_mask="r" fsuid=1002 ouid=1002
I could not see the error Marc is reporting, because I don't know how
exactly I should run obfsproxy to trigger it. Marc, could you please
share the exact command line you're running?
Lunar, unless you disagree I'll do a team upload that disables this
profile by default. We can re-enable it if/once someone feels like
keeping it up-to-date and working. What do you think?
Cheers,
--
intrigeri
Sascha Steinbiss:
> Can anyone else in the team reproduce this issue or probably comment?
I can't reproduce this on current sid.
Control: tag -1 + fixed-upstream
intrigeri:
> So we're now only waiting for the tails-installer fixes to be released
> upstream
Done in 5.0.2, that's been packaged as 5.0.2+dfsg-0tails1 for Tails already.
I've tested it on Debian sid and it works fine for me.
> and
r we ship it via isc-dhcp-client
(synchronizing it regularly from src:apparmor) or in the
apparmor-profiles package.
Cheers,
--
intrigeri
Ben Hutchings:
> Yes, I now understand this. I'll add a Recommends: apparmor for the
> next upload so this broken configuration is less likely to occur.
Thanks!
Cheers,
--
intrigeri
uot;unrelated" breakage
has been fixed, and the reasons behind it clarified. What do
you think?
Cheers,
--
intrigeri
Viktor Jägersküpper:
> I confirm that with this change tor starts normally without apparmor
> installed.
Thanks a lot for testing & reporting back!
n and I fully concur.
Cheers,
--
intrigeri
8
Both were merged, part of new upstream releases, and have landed
in sid.
So we're now only waiting for the tails-installer fixes to be released
upstream and then uploaded to Debian.
Cheers,
--
intrigeri
d avoid breaking the startup of the unit in case of such
problems with the AppArmor profile. Weasel, what do you think?
Cheers,
--
intrigeri
uld be. Shall we silence the denial or allow it (possibly prefixed
with "owner" to avoid increasing the attack surface too much)? Once we
reach a conclusion here I'm happy to send a patch upstream.
Cheers,
--
intrigeri
have been submitted to the corresponding projects already:
- https://github.com/storaged-project/udisks/pull/416
- https://github.com/storaged-project/libblockdev/pull/288
The corresponding Tails upstream bug is:
https://labs.riseup.net/code/issues/14809
Stretch is not affected.
Cheers,
--
intrigeri
/usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages rss2email depends on:
ii python 2.7.14-1
ii python3 3.5.3-3
ii python3-feedparser 5.1.3-3
ii python3-html2text 2016.9.19-1
Versions of packages rss2email recommends:
ii python3-bs4 4.6.0-1
Versions of packages rss2email suggests:
pn esmtp
-- no debconf information
--
intrigeri
Jan Luca Naumann:
> I have prepared a version for 4.11 and upload it as soon as I have
> tested it (at the moment I'm blocked by https://bugs.debian.org/869511 )
Now 4.12 is in sid and I believe there's no blocker anymore :)
… assuming there's an updated aufs patchset for 4.12.
oint-perl: libhtml-html5-parser-perl
librdf-rdfa-parser-perl: libhtml-html5-parser-perl
Cheers,
--
intrigeri
Hi,
Russ Allbery:
> Yeah, go for it.
Thanks for your quick answer!
I've filed a removal request:
https://bugs.debian.org/870494
Cheers,
--
intrigeri
gregor herrmann:
> +1 for removal.
Done: https://bugs.debian.org/870495
Jonas Smedegaard:
> Quoting intrigeri (2017-08-01 16:38:06)
>> Jonas, what do you think?
> Please request removal - also of the reverse dependency.
Done: #870437
intrigeri:
> that's a leaf package, with 2 votes on popcon,
And now: 1.
> that made it into one
> single stable release ⇒ unless I missed a compelling reason to keep
> it, I would simply get the package remove from sid.
There's a pull request opened since February
(https:
king further on this problem?
Would you mind if we removed this package from sid?
Cheers,
--
intrigeri
Niko Tyni:
> There's been no reaction on the upstream bug, and the last upstream
> release was in 2002. There are no reverse dependencies. I suggest
> removal unless somebody objects?
Requested: https://bugs.debian.org/870424
o go ahead and request
the removal of this package + its reverse-dependency from sid, unless
someone is interested enough in this package to work on a fix (that
might be in DateTime-Event-Recurrence or elsewhere).
Jonas, what do you think?
Cheers,
--
intrigeri
Hi shirish!
> I purged and reinstalled amd getting the same error -
Do you mean you purged the package, or also ~/.local/share/torbrowser/?
Antoine Beaupré:
> PS: seems to me like a good example why profiles-extra should be
> deployed straight to /etc :p
One step at a time: I'd rather see AppArmor enabled by default with
a small, robust policy first. And then we can think of extending this
policy :)
Cheers,
--
intrigeri
find any such thing in a Stretch chroot after installing
apparmor-profiles. I've looked in
/usr/share/doc/apparmor-profiles/extras/ and in /etc/apparmor.d/.
Perhaps you copied stuff from /usr/share/doc/apparmor-profiles/extras/
to /etc/apparmor.d/ in the past and your own copy needs an update?
Cheers,
--
intrigeri
t. the future of Tails' on-disk format and
installation methods, and hence wrt. the future of this package: this
will allow us to determine how suitable this package is for Buster.
Cheers,
--
intrigeri
Hi,
Holger Levsen:
> On Mon, May 22, 2017 at 12:12:39PM +0200, intrigeri wrote:
>> Fundamentally, do you disagree with the main point this bug report is
>> about i.e. "Should not be part of Stretch"?
> yes, somewhat, but I acknowledge that it's not my call.
&g
via stable-security or
stable-updates?
Cheers,
--
intrigeri
sts for
some packages of "mine"), but IMO this shouldn't block the Stretch
release, so a stretch-ignore tag would seem suitable to me.
Cheers,
--
intrigeri
Hi,
Antoine Musso:
> python-jenkins 0.4.11 is partly broken.
At least the jenkins-job-builder use case works fine for me on current
Stretch, and the bug report says "partly", so I'm not sure this bug
should really be RC.
Cheers,
--
intrigeri
on't ensure that busybox is installed when the cryptsetup hook
needs it though. But that's another problem, and as Guilhem pointed
out it's well tracked elsewhere already.
Cheers,
--
intrigeri
vor downgrading the severity and
> merging the bugs for the time being.
Makes sense to me!
Cheers,
--
intrigeri
, while cryptsetup might not be
So at this point, I suggest this bug is reassigned to cryptsetup, and
option 3 is implemented there. But downgrading to non-RC and leaving
things as-is seems acceptable to me as well.
Thoughts?
Cheers,
--
intrigeri
101 - 200 of 615 matches
Mail list logo
