Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
* Paul Wise [130802 15:54]: > > In any case, removing md5 support seems like a bad idea to me right > > now, as older software might not have been adapted to check the other > > hashes, or would imply breaking the current .dsc and ,changes formats, > > as the Files field uses md5. > > We've had SHA1 since before snapshot.d.o data started (2005), I would > guess any relevant software would have been updated in the last 8 > years. In 2008 ubuntu had Sha256Sums wrong which showed that back then almost not software even bothered to check those fields: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/243630 non-md5sum hashses in Sources generated by DAK were incomplete until the generation code moved away from apt-ftparchive (early 2011 I think), thus only the Files: part with md5sums was the only reliable way to get the list of all files belonging to it. Support for non-md5sum hashes was added to dpkg-scansources/apt-ftparchive with apt (0.7.25.3) released to unstable 2010-02-01, first released with squeeze. So it is not some 8 years. It is more "since squeeze" that Debian and some of the common tools even produce complete non-md5sum hashes in Sources indices. reprepro for example only tries to support source indices without "Files" (i.e. md5sum hashes) since 4.12.0 (i.e. since wheezy). Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803075234.ga3...@client.brlink.eu
Finding correct component for Virtual Box / Debian / screen resolution issue
Hi, TL;DR Debian installed inside Virtual Box (on a Debian host) does not support higher resolutions than 1024x768 when there are no Virtual Box guest additions installed. Whats the correct component to report a bug/wishlist request against? Long version: Before asking on debian-devel, I respected previous advice, asked two people in private and reported a bug against Virtual Box. [1] However, I am not positive, I am getting a reply within a year (or ever). [2] And its not yet clear, if Virtual Box is the correct component to report against. Upstream (a Virtual Box forum moderator) says its not an upstream bug. [5] Quote: > Then you need to adjust the framebuffers of the guest. Since you > are negating the guest additions it is all up to you and the guest OS. > Custom xorg.conf would help too depending on the OS. But this is > all out of the scope of this forum since it does not deal with VirtualBox. Generally, I am not sure if there is a better mailing list for "whats the correct component" type questions. I am ready to accept any "we don't care, provide a patch or wait forever" response, once the concerned component/maintainer has been found. At the moment, I don't think I found this component/maintainer. Cheers, adrelanos [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714481 [2] Debian Virtual Box has other standing bug reports without replies within a year. I doubt these bugs are introduced by Debian, it looks more like upstream bugs. [3] [4] [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633751 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675208 [5] https://forums.virtualbox.org/viewtopic.php?f=3&t=55284 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fccd92.8030...@riseup.net
Re: Finding correct component for Virtual Box / Debian / screen resolution issue
We need to implement DEP-11 so that we can map hardware (and other things) to packages. isenkram/PackageKit needs to be extended to use DEP-11 information. isenkram (or similar DEP-11 solution) needs to be run from the Debian installer. This will mean that installs using d-i will automatically install virtualbox-guest-x11/virtualbox-guest-dkms. It also means that when you move a physical machine into VirtualBox, PackageKit/isenkram should prompt you to install these packages. I would suggest avoiding VirtualBox though. Oracle seems to having an adverse effect on VirtualBox, for example it recently had to move to contrib. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6ebikxmr2j-p2tzpun+kkoq-0rkyr_93ec-ueqgsq-...@mail.gmail.com
Re: Finding correct component for Virtual Box / Debian / screen resolution issue
Paul Wise: > This will mean that installs using d-i will automatically install > virtualbox-guest-x11/virtualbox-guest-dkms. This question is about Virtual Box / Debian / screen resolution without having guest additions installed. (It should work. Grub can do higher resolutions in grub boot menu as noted in my bug report. Why Linux can not?) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51fcd4c3.1070...@riseup.net
Re: Bug#704594: python-debian: switch ar implementation to python-arpy
Christoph Egger writes: >> The python-arpy package in the NEW queue doesn't have a python3 version, so >> this would regress python-debian. You might want to fix this first. > > Support is there upstream. I just need to figure out how to build the > python3 variant Fixed Christoph -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871u6bdqdt@mitoraj.siccegge.de
Bug#718631: ITP: t4kcommon -- common library for tux4kids
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,hol...@debian.org Package name: t4kcommon Version: 0.1.1 Upstream Author: David Bruce and others URL: http://tux4kids.alioth.debian.org/ License: GPL-3+ Description: common library for tux4kids t4k-common is a library of code shared between tuxmath and tuxtype. This library is a new requirement for updated "tuxmath". -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201308032052.01645.only...@member.fsf.org
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Fri, 2013-08-02 at 15:29 +0200, Guillem Jover wrote: > > I was wondering if it is time to drop or deprecate MD5 from the apt > > metadata and replace it with SHA512 and or SHA-3. Thoughts? > > Adding stronger hashes support seems in general like a good idea, but > I've never quite understood the urge to remove weaker ones in case > these get accumulated instead of replaced, as more hashes should also > in general imply a harder time coming up with data that will produce > all the same hashes. You don't need to match all of them though, just the strongest hash that your target is actually checking. So if we drop md5 we will flush out all those utilities which rely only on md5 which will, eventually, lead to an increase in the strongest hash which targets are checking and prevent attackers from only supplying md5. > In any case, removing md5 support seems like a bad idea to me right > now, as older software might not have been adapted to check the other > hashes, or would imply breaking the current .dsc and ,changes formats, > as the Files field uses md5. Right, but perhaps dropping md5 should become a longer term goal? Did debian-devel have not this same conversation not so long ago? I'm getting that deja vu feeling... Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1375525839.15681.63.ca...@dagon.hellion.org.uk
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Sat, Aug 3, 2013 at 12:30 PM, Ian Campbell wrote: > Did debian-devel have not this same conversation not so long ago? I'm > getting that deja vu feeling... Yes: http://lists.debian.org/1349911198.3341.117.ca...@fermat.scientia.net I probably should have searched the archives before posting, sorry. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EOEEL3KOajiUeUOGCL+bq0gOYcp7uRM8OPt=szjqk...@mail.gmail.com
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Fri, Aug 2, 2013 at 8:57 PM, David Kalnischkies wrote: > On Fri, Aug 2, 2013 at 6:33 PM, Ondřej Surý wrote: > > On Fri, Aug 2, 2013 at 2:52 PM, Paul Wise wrote: > > So, yeah let's drop MD5, but don't introduce neither SHA512 nor SHA-3 > > unless there's a cryptographical need (there isn't at the moment). > > Actually, it might be less controversial to drop SHA1[0] as the MD5 has > fieldnames (as Guillem already mentioned) which are probably assumed > to be present. I have not check(-ETIME) that for APT now, but somehow > I would be surprised if it wouldn't dislike (some) missing MD5 sections > even if it isn't using the sections for providing MD5, but because they > have > a wonderfully stable name like "Files". > > Its not like we are anywhere near to a "cryptographical need" to drop MD5 > (as you have to do (at least) two pre-image attacks in a row with the same > file (aka compressed and uncompressed) – and as a bonus, the filesize has > to match as well – not to mention that the file has to make sense…) and > at the time we do SHA1 is probably not an interesting candidate. > [IANACryptoguy] As far as I understand the MD5 attacks the length doesn't matter. You just need to pick the package big enough to hold your evil content and the "filling" which you use to compute the same MD5 (e.g. collision vulnerability). I think that the lengths of the files do not add enough bits. As for compressed/uncompressed - again I am unsure if this adds enough bits to circumvent the attacks on MD5. In my simplistic view - if you can find a collision in digital certificate then I am quite sure you can find a collision in debian package. I would not rely on MD5 with anything, so the dropping of MD5 for good (together with SHA-1) might be a good release goal. O. -- Ondřej Surý
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Sat, Aug 3, 2013 at 1:34 PM, Paul Wise wrote: > On Sat, Aug 3, 2013 at 12:30 PM, Ian Campbell wrote: > > > Did debian-devel have not this same conversation not so long ago? I'm > > getting that deja vu feeling... > > Yes: > > http://lists.debian.org/1349911198.3341.117.ca...@fermat.scientia.net > > I probably should have searched the archives before posting, sorry. JFTR (from re-reading the dejavu :) I think it's useless to upgrade to SHA512 (or SHA-3), but at the same time I think we should drop MD5/SHA-1 in .changes/.dsc files (and Release.gpg). Using MD5 for debsums is just fine - the algorithm there needs different properties and any good checksum algorithm would do. (Even CRC-32 or Alder-32 would be fine, I guess...) O. -- Ondřej Surý
Re: Finding correct component for Virtual Box / Debian / screen resolution issue
On Sat, Aug 3, 2013 at 12:00 PM, adrelanos wrote: > This question is about Virtual Box / Debian / screen resolution without > having guest additions installed. I see, is there any reason to not do that? Anyway, looking at the Xorg.log you posted, it is using VESA. It rejects (various reasons) all the modes returned by the virtual firmware and uses some hard-coded built-in modes instead. Probably this is either #566153 or #563203 and I think has been present forever; I always assumed VESA didn't have a mechanism to do anything higher than 1024x768. > (It should work. Grub can do higher resolutions in grub boot menu as > noted in my bug report. Why Linux can not?) I missed that point. Do you know which driver/module grub is loading to achieve that? I expect it is using VESA and trusting the virtual firmware instead. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6fkvqn3sw4osr1ejc+ngcwcejc5_vaacizt178jofg...@mail.gmail.com
Bug#718642: ITP: fr24feed -- Forward ADS-B messages to feed flightradar24.com
Package: wnpp Severity: wishlist Owner: "Adam Cécile (Le_Vert)" * Package name: fr24feed Version : 0.0+233.20130709 Upstream Author : Flightradar24.com * URL : http://forum.flightradar24.com/threads/4270-Linux-feeder-software-for-Flightradar24 * License : non-free Programming Lang: C Description : Forward ADS-B messages to feed flightradar24.com Official feeding software from flightradar24.com . It can be used along dump1090 to receive ADS-B flight messages and forward them to flightradar24.com database. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803123029.19492.34617.reportbug@thrall.courc.levert
Re: Finding correct component for Virtual Box / Debian / screen resolution issue
On Sat, Aug 03, 2013 at 11:49:57AM +0200, Paul Wise wrote: > This will mean that installs using d-i will automatically install > virtualbox-guest-x11/virtualbox-guest-dkms. It also means that when > you move a physical machine into VirtualBox, PackageKit/isenkram > should prompt you to install these packages. > > I would suggest avoiding VirtualBox though. Oracle seems to having an > adverse effect on VirtualBox, for example it recently had to move to > contrib. While the host part indeed needs to be contrib because a bit of 16 bit code requires a non-free compiler, and the alternative, EFI, is not really ready, I consider having the _guest_ outside main to be a packaging error. Mostly because it prevents d-i from supporting VirtualBox. I reported this as #709899. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803144905.ga28...@angband.pl
Re: new hashes (SHA512, SHA3) in apt metadata and .changes files?
On Sat, 03 Aug 2013, Ondřej Surý wrote: > [IANACryptoguy] As far as I understand the MD5 attacks the length doesn't > matter. You just need to pick the package big enough to hold your evil > content and the "filling" which you use to compute the same MD5 (e.g. > collision vulnerability). I think that the lengths of the files do not add > enough bits. For length to make a sucessfull collision attack considerably harder, your signature must include the length, i.e. it should be something like "hash, length", not just the hash. I.e. you need to know the length of the original message/data somehow, not just its hash. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803173235.gc10...@khazad-dum.debian.net
Re: fotoxx: new upstream version available
On Sat, Apr 06, 2013 at 07:18:50PM -0300, Santiago Torres Batán wrote: > Hi, sorry for the delay. > Yes, I'm active. I was waiting the new realease to find a sponsor and work > with the new version of the package. > > Thanks for the bug reports. I'm going to check them out. Hi, did you find a sponsor? Fotoxx version 13.08 has just been released. The Debian package is really outdated. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803234422.5EM80HoZk@outer-rim
Re: Status of deb(5) format support in Debian
On Fri, Aug 02, 2013 at 04:09:20AM +0200, Guillem Jover wrote: > The other side of the support I've been pondering about is extending > dpkg-deb so that .deb files can be modified in conformant ways, stuff > like inserting _-style members, or appending extra ones at the end, > which would cover the needs of several other tools. For the Ubuntu archive, it bothers me that it currently has code that pokes about with ar to verify that the .deb has a sane format. I don't see a way to do this efficiently with dpkg-deb, though; "dpkg-deb -I" stops at the control member and doesn't even care if the data member is entirely missing, while "dpkg-deb --fsys-tarfile" and similar will process the entire data member, which will be inefficient on large .debs. If I haven't just missed something, would it be possible to have a "dpkg-deb --verify" option that just checks for conformance with deb(5)? That would be simpler for this application than having to write new bindings against a (new?) libdpkg interface. That said, the manual verification does give us the ability to have the archive enforce things like "amazing new compression support is only available as of $release", which is perhaps useful. So maybe the dpkg-deb option shouldn't be just an assertion, but should instead print out a machine-readable list of properties of the .deb; then we could check which properties are permitted. What do you think? -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130803222530.ga29...@riva.ucam.org
Bug#718664: ITP: htseq -- high-throughput genome sequencing analysis.
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-CC: debian-...@lists.debian.org, debian-devel@lists.debian.org Package name: htseq Version: 0.5.4p3 Upstream Author: Simon Anders URL: http://www-huber.embl.de/users/anders/HTSeq/doc/overview.html License: GPL-3+ Programming Lang: Python Description: HTSeq can be used for a number of common high-throughput genomics analysis tasks. . * Getting statistical summaries about the base-call quality scores to study the data quality. * Calculating a coverage vector and exporting it for visualization in a genome browser. * Reading in annotation data from a GFF file. * Assigning aligned reads from an RNA-Seq experiments to exons and genes. Remark: This package is maintained in the Debian Med team and available in VCS at: git://git.debian.org/debian-med/python-htseq.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2311425.jqM50mftGK@myrada
Re: Status of deb(5) format support in Debian
Hi! On Sat, 2013-08-03 at 23:25:30 +0100, Colin Watson wrote: > On Fri, Aug 02, 2013 at 04:09:20AM +0200, Guillem Jover wrote: > > The other side of the support I've been pondering about is extending > > dpkg-deb so that .deb files can be modified in conformant ways, stuff > > like inserting _-style members, or appending extra ones at the end, > > which would cover the needs of several other tools. > > For the Ubuntu archive, it bothers me that it currently has code that > pokes about with ar to verify that the .deb has a sane format. I don't > see a way to do this efficiently with dpkg-deb, though; "dpkg-deb -I" > stops at the control member and doesn't even care if the data member is > entirely missing, while "dpkg-deb --fsys-tarfile" and similar will > process the entire data member, which will be inefficient on large > .debs. > > If I haven't just missed something, would it be possible to have a > "dpkg-deb --verify" option that just checks for conformance with deb(5)? > That would be simpler for this application than having to write new > bindings against a (new?) libdpkg interface. Ah, I like that, I've noted it down to come back to it when I rework the dpkg-deb code. I could also just modify -I to check for the data member, but the output is not easily parseable and a --verify option seems better in all other ways. But, a full --verify would need to process the data.tar also to check if it's comformant, so you'd get bad performance on that too. But it could just have different modes, like just for the 'container' or 'full' or something along those lines. > That said, the manual verification does give us the ability to have the > archive enforce things like "amazing new compression support is only > available as of $release", which is perhaps useful. So maybe the > dpkg-deb option shouldn't be just an assertion, but should instead print > out a machine-readable list of properties of the .deb; then we could > check which properties are permitted. What do you think? I like that too, it could either be part of --verify --verbose, or a new option, the output could be deb822-style. Also noted. But feel free to file a bug report if you want. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130804004026.ga14...@gaara.hadrons.org
