Re: DSA-3708-1 mat -- security update (What are MAT users to do)?
Robert Haist: > For PDFs you can use exiftool from the libimage-exiftool-perl to remove > metadata: > exiftool -all= example.pdf > This works for me. Does this address the problem (metadata in embedded images) that triggered us from removing this functionality from MAT?
Re: DSA-3708-1 mat -- security update (What are MAT users to do)?
Hi, gwmfm...@unseen.is: > This email is in response to www.debian.org/security/2016/dsa-3708 > I relied on MAT (Metadata Anonymisation Toolkit) on a daily basis to remove > the > metadata from PDFs as it is a requirement for my job. I must have this > ability. > I appreciate the effort to fix this bug but it was not a major issue for me > because > the PDFs I encounter did not have images. Now that MAT cannot deal with PDFs > at all, > I am forced to use Windows (which I hate) because I cannot find a suitable > alternative to MAT. I'm sorry about that. FYI this affects me as well as a lot of Tails users. > Can anyone please suggest a Debian solution to my current problem? I'm not aware of any :/ > I am assuming that Debian Stretch Stable (2017 release) will have an > updated version of MAT that will again process PDFs? This is unlikely, but who knows: perhaps someone will show up and contribute patches upstream (https://0xacab.org/mat/mat/issues/11067). Cheers, -- intrigeri
Re: Verification of downloads/mirrors from $MIRROR//debian/dists/jessie/main/installer-amd64/
Hi, Mirko Vogt: > Is there any way for me to verify the > downloaded installer which I seem to need when using `virt-install` in > conjunction with a preseed-script? Recent di-netboot-assistant might provide means to solve this problem: its changelog entry for 0.39 reads "Implement the inclusion of debian-installer packages". But I did not look closer yet. If you do, please provide feedback on https://bugs.debian.org/775904 :) Cheers, -- intrigeri
Re: goals for hardening Debian: ideas and help wanted
Hi, Giacomo Mulas wrote (24 Apr 2014 16:49:20 GMT) : Good to know, actually I had tried apparmor quite some time ago and did not try again. I will give it another spin as soon as I can. https://wiki.debian.org/AppArmor/HowTo :) However, I do not agree that I should file bugs against apparmor if a debian package does not work properly, it should go to the package manager (and maybe cc to some apparmor expert team). It cannot be the maintainer(s) of apparmor to have to shoulder the effort of creating and maintaining profiles for all debian packages. They may be called in for support, but regular package maintainers should be involved IMHO, otherwise it will never really take off and provide significantly better security. IMO, the bug should be filed against the package that ships the profile: it's not a bug in the apparmor package, that other packages may feed it with a buggy configuration. Now, most package maintainers currently don't use AppArmor, and they may upload AppArmor profiles (e.g. provided by upstream) that won't work as-is in Debian. We have no clear consensus that we should invest time, distro-wide, to support AppArmor in Debian, so I don't think we can blame anyone for this. At least they're giving a chance, for anyone interested, to actually test these profiles, enjoy it when it works, and report bugs otherwise. If the profile is shipped in the same package as the software (as opposed to what comes from apparmor-profiles), and if the maintainer lack the resources and/or the interest to take care of such bugs, then they still have two useful options: * ask the AppArmor profiles team (Cc'd) for help to fix the profile, in order to go on shipping it along with the software it's about; that would be my preferred solution, whenever applicable; * drop the profile from their package altogether, and ask pkg-aa-profiles for inclusion in the upcoming apparmor-profiles-extra package. I still hadn't time to properly announce the pkg-aa-profiles team, so no wonder it hasn't taken off yet. Help is welcome: https://wiki.debian.org/AppArmor/Contribute If interested in more background information: https://lists.debian.org/debian-security/2014/01/msg8.html Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/85r431h513@boum.org
Re: gpg signatures for Jessie images
Patrick Schleizer wrote (18 Jan 2014 18:45:40 GMT) : Wheezy, http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-dvd/ does not contain gpg signatures. Can you offer gpg signatures for Jessie as well please? I suspect that writing to the Debian CD team would have more chances to work, since they are the ones (I guess) who produce these images. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85zjmtjf2k@boum.org
Re: Updated plans for AppArmor support
intrigeri wrote (03 Jan 2014 02:21:59 GMT) : The wiki page does not reflect this strategical move of mine yet, sorry. The wiki pages were updated: https://wiki.debian.org/AppArmor/Contribute https://wiki.debian.org/AppArmor/Progress ... and I have a preliminary apparmor-profiles-extra package ready locally. I'm going to include one more profile or three, and upload. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85y52iqz6s@boum.org
Re: Enhancements/enabled hardening flags in Wheezy pkgs/release.
Hi, Moritz Mühlenhoff wrote (02 Jan 2014 18:31:07 GMT) : The following packages have had a DSA in the previous years, but do not use hardened build flags. Thanks for updating the list! pixman Patch submitted (#733986). libotr I'll take care of that one too. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85vby2gjwg@boum.org
Updated plans for AppArmor support [Was: Enhancements/enabled hardening flags in Wheezy pkgs/release.]
Hi all,
I'm taking this opportunity to share a bit about my experience and
plans for improving AppArmor support in Debian = cc'ing the
potentially interested parties: AppArmor maintainer in Debian,
upstream mailing-list, Tails developers and Jake. If I've forgotten
someone, I'm sorry, please forward as you see fit.
Daniel Curtis wrote (02 Jan 2014 23:36:04 GMT) :
Anyway, it could be very nice if *Debian* would start to
implement *AppArmor* for serious
AppArmor is already usable on Wheezy:
https://wiki.debian.org/AppArmor
Daniel, I can understand that you don't see this as serious. In the
last two years, I've been conducting this merely as a side project,
and did not put much energy into bootstrapping an organized team
around it. Feel free to join me and make it more serious :)
I personally expect to be able to allocate substantially more
resources to this project in 2014Q3 and Q4 than what I've done in the
past (hint: the roadmap for the Tails 2.0 milestone includes AppArmor
confinement for a few apps). It will probably be too late for having
something really big in Jessie (*if* I do it alone), but I am
confident that we will ship many more confinement profiles in Jessie
than in Wheezy.
Flashback, my focus in the last two years was: testing, improving and
maintaining profiles; slowly being done in collaboration with the very
kind upstream and Ubuntu folks. I think I've now been doing this for
long enough to be able to make a realistic evaluation of the effort it
takes to maintain a set of profiles I find relevant for testing/sid
= does not seem crazy, time to go public.
Next step: I plan to create a apparmor-profiles-extra package with
most of the profiles that Ubuntu spreads over individual packages;
keeping it all in one place, maintained by those who are interested.
Stefano Zacchiroli easily convinced me that it would better match the
current state of AppArmor adoption and expertise among Debian
maintainers than the Ubuntu model, where:
* AppArmor is enabled by default, so expertise in this area is more
widespread among many kinds of contributors;
* it is my understanding that AppArmor profiles are mostly
maintained by a relatively small set of people, who are experts in
this area;
* the AppArmor experts can easily update profiles by pushing changes
to any package's VCS repository, thanks to the no strong
ownership of packages model.
If this works out well, then enabling AppArmor + installing
this -extra package on Jessie should give you roughly the same level
of AppArmor support as provided by Ubuntu 13.$something. Note that we
will probably always lag a bit behind: at the time a new Ubuntu
release is put out, it often ships a lot of AppArmor features, patches
and improvements that have not made their way in any upstream AppArmor
or Linux release yet; I don't think we would easily gather within
Debian the resources needed to do the same amount of
{back,forward}porting, integration and QA work. And even if we did,
our upstream first culture would probably make us *not* want to do
this. That's not a competition anyway, and I'm confident we manage to
collaborate between different projects, despite our different agenda
(especially regarding the app store use case and MAC isolation for
lightweight containers hardening, that are currently leading the
efforts Ubuntu puts into AppArmor front as I understand it).
Let's bootstrap something useful and then we'll see if the project
wants it enabled by default; then only, it will be worth reconsidering
to spread AppArmor profiles over individual packages, and possibly to
either give a dedicated team a NMU wildcard for liberal NMUs that
touch only the AppArmor bits, and/or to move the responsibility to
maintain it over maintainers' shoulders if they wish. I have no idea
what Debian as a project may prefer in this area, and I think it's too
early to try guessing. Let's do some more homework first. The wiki
page does not reflect this strategical move of mine yet, sorry.
Feedback and help are warmly welcome :)
(Oh, and Michael Stapelberg was kind enough to provide me, in a matter
of minutes, with a draft patch that adds explicit AppArmor profile
loading support to systemd, for the rare cases that need this kind of
things, such as the Tor package. I've been meaning since DebConf13 to
trace it and debug why the first iteration of this patch does not work
for me. My current Tor unit file uses aa-exec, and it works fine for
me, so I've had no strong incentive to work on the nicer way to do
it... yet.)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/85ob3tpzy0@boum.org
Re: parcimonie [Was: Check for revocation certificates before running apt-get?]
Paul Wise wrote (24 Dec 2013 05:49:34 GMT) : The author claims it has an advantage over parcimonie of using unique Tor circuits for each key fetch. Personally I don't think bash is the appropriate language to implement this though. https://github.com/EtiennePerot/parcimonie.sh Indeed, the author writes: Unlike the original Parcimonie, parcimonie.sh guarantees that each key refresh happens over a unique Tor circuit even when multiple refreshes happen at the same time. (How?) I find this phrasing slightly confusing and potentially misleading, but still, what I believe it really means is entirely correct: while parcimonie does not do multiple refreshes at the same time, indeed, if the user *manually* triggers a key refresh on their own, it may very well used the same circuit that parcimonie (has used last|is using right now|will be using next time). This feature would be trivial to add to parcimonie (not writing the original parcimonie, as IMHO it's the responsibility of the other implementation to not reuse an identifier that's already taken in the global namespace, not mine to differentiate from his). (OT: I was thinking last night of getting rid of the DBus bits in parcimonie, and instead implement a way for the daemon to report the success/failure details in a computer-readable format on stdout, and have the applet 1. run the daemon itself 2. read its stdout 3. present it to the user. This would probably be more lightweight both in terms of memory footprint, and in terms of the size of the codebase that one may want to audit and/or trust.) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85eh52eh2w@boum.org
Re: parcimonie [Was: Check for revocation certificates before running apt-get?]
Hi, Paul Wise wrote (15 Dec 2013 06:28:53 GMT) : On Sun, Dec 15, 2013 at 2:13 PM, Darius Jahandarie wrote: This thread is probably not the most apropos place to bring this up, but I've found parcimonie to be an terribly over-complex implementation of the (good) design document that they wrote. [...] Agreed. I've long thought it should have been written in C and included in GnuPG itself, as gpg-keyring-refresh-daemon or something like that. As the author of parcimonie, I can only agree it would be great if someone took it over and made it more lightweight. My initial priority was to have something that works, and I'm glad if it paves the way for something better. FWIW, the next upstream release will use Moo, instead of Moose, so will be a bit more lightweight both in terms of dependencies, and of memory footprint (especially once I get to port GnuPG::Interface to Moo). Are there specific pieces of the implementation that seem too complex to you, or any available option that could be dropped in your opinion? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wqj6phft@boum.org
Re: How (un)safe would Debian be when only using the security.debian.org repository?
adrelanos wrote (10 Nov 2013 19:50:12 GMT) :
Or the same question in other words: are sometimes updates fixing
security issues released though repositories other than the security
repository?
Yes: see every {,old}stable point-release release notes.
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
--
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8561s0ovpn@boum.org
Re: SSL for debian.org/security?
adrelanos wrote (29 Oct 2013 11:53:06 GMT) : Downloading apt-get updates over Tor hidden services would be awesome! I don't think there is anything preventing anyone from running a Debian mirror over a Tor HS. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3gw1aj8@boum.org
Re: Compromising Debian Repositories
Hi, I need a reality check, as it's unclear to me what are the goals of this discussion. Does anyone involved plan to work on improving things, and then we're discussing where it would be best to focus their energy? If that's the case, then I suggest we try to design solutions with baby steps that can realistically be implemented on the short term. Or is the goal simply to assess the security of our current infrastructure in various threat models? If that's the case, then how about clearly writing these threat models so that we can then reason on the same basis? Or is the goal something entirely different that I missed? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85k3k0tuv2@boum.org
Re: Compromising Debian Repositories
Hi, adrelanos wrote (04 Aug 2013 03:04:33 GMT) : Volker Birk: On Sat, Aug 03, 2013 at 10:38:34AM +, adrelanos wrote: Volker Birk: On Sat, Aug 03, 2013 at 09:16:40AM +, adrelanos wrote: That should help to defeat any kind of sophisticated backdoor on build machines. Really? How do you detect, if maintainer's patches contain backdoors? Someone else builds the same package (binary) and detects a different checksum. - That required deterministic builds. There will be the correct checksum, if the maintainer of the package does it. Why? So no way to detect that with deterministic builds. Why not? I believe you have missed something around if maintainer's patches contain backdoors. Maintainer's patches are part of the source package, and applied to the source before the binary package is built. As you can see, it's obvious checksums and deterministic builds don't help in such a case. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85li4hx5b0@boum.org
Re: status of introducing security mechanisms in Debian
Hi, berta...@ptitcanardnoir.org wrote (09 Feb 2011 20:35:12 GMT) : 2011/2/9 intrigeri intrigeri+deb...@boum.org: Will anyone take care of using it to update the aforementioned wiki page? Done, at least for the userland part, which this page is dedicated for. Thanks a lot. Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Did you exchange a walk on part in the war | for a lead role in the cage? -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85zkq3d2wz@boum.org
Re: status of introducing security mechanisms in Debian
Hi, Including compile time hardening options has been discussed for a long time, but efforts is probably laking of people willing to push it. You can see some historical pages on the wiki [1]. Thank you, Mircan, Kees and bertagaz for providing all these up-to-date pieces of information that is currently hard to gather. Will anyone take care of using it to update the aforementioned wiki page? Bye, -- intrigeri intrig...@boum.org | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc | Do not be trapped by the need to achieve anything. | This way, you achieve everything. -- To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85wrl9vbrd@boum.org
