Re: [gentoo-dev] Re: RFC: lzma tarball usage
Doug == Doug Goldstein [EMAIL PROTECTED] writes: Doug If you read the lzma changelogs, it appears to imply that newer Doug ones won't be able to read older formats. The changelog Doug specifically states if a user they are handling the issue Doug gracefully by telling the user to upgrade or downgrade their Doug lzma. My understanding is that the new utils will be able to uncompress current archives, but will not be able to create them and also will be unable to convert current archives to the new format w/o a full (and time-consuming) uncompress/compress cycle. -JimC -- James Cloos [EMAIL PROTECTED] OpenPGP: 1024D/ED7DAEA6 -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: lzma tarball usage
Ulrich Mueller [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 07 May 2008 16:55:39 +0200: The decoder of lzma-utils is also written in C only. So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: lzma tarball usage
Duncan [EMAIL PROTECTED] writes: So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. (BTW I considered using lzma for backup compression, but I didn't get much different results from bzip2 in term of size, but took quite longer in case of compression... I still have some doubts whether lzma is worth it). -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpRSDaMmZtfS.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
[EMAIL PROTECTED] (Diego 'Flameeyes' Pettenò) writes: USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. Should that be USE=-cxx? The help for USE=cxx says that this builds support for C++. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: RFC: lzma tarball usage
Graham Murray [EMAIL PROTECTED] writes: Should that be USE=-cxx? The help for USE=cxx says that this builds support for C++. It was meant as setting a cxx USE on the ebuild, I wasn't certainly meaning to disable the C++ parts with USE=cxx enabled ;) -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpZoYJGuVAYM.pgp Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008, Diego 'Flameeyes' Pettenò wrote: So it would also be possible to compile lzmadec without any need for C++. Just call make in subdirs liblzmadec and lzmadec. What about USE=decode-only or something similar for lzma-utils, then? If desired, it could even be masked on normal profiles, but would then be there for the embedded and releng folks. USE=cxx should do just fine, it will disable the C++-related parts, whatever they are. Sincerely I'd quite like to enable it on my vserver's build chroots too. See https://bugs.gentoo.org/show_bug.cgi?id=220899 for a first attempt of an ebuild. Ulrich -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ryan Hill wrote: On Wed, 07 May 2008 16:23:12 +0300 Mart Raudsepp [EMAIL PROTECTED] wrote: Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce According to the mailing list this change was done to fix security holes in the format and also resulted in a slightly different format that's incompatible with the previous verion. So lzma 5.x and higher will be a different on disk format. It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh wrote: On Thu, 08 May 2008 09:32:34 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs), and it's had security issues. Fair enough. However, newer GNU tar's are able to untar the older formats. If you read the lzma changelogs, it appears to imply that newer ones won't be able to read older formats. The changelog specifically states if a user they are handling the issue gracefully by telling the user to upgrade or downgrade their lzma. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
Doug Goldstein wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Some of the other fun bits are lzma requires autotools but autotools are going to be compressed with lzma. So if we ever need to autoreconf, we have a chicken/egg issue. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:32:34 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. You mean projects like 'GNU tar'? As far as I know Ciaran, all GNU projects have switched or are in the process of switching to lzma over bzip2. I believe the issue in question which prompted this original e-mail was due to coreutils. But I could be wrong. You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs), and it's had security issues. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
Ciaran McCreesh [EMAIL PROTECTED] writes: You miss my point. GNU tar sometimes changes its on disk format (and will be doing so again at some point for xattrs) It's not really important to the discussion, but... The TAR format is designed as such that on disk formats can be extended without breaking entirely backward compatibility. For what it's worth, extended attributes and ACLs are already supported by star (Schilling's) and bsdtar (libarchive). The fact that GNU tar doesn't support them at the moment is a different problem. On the other hand, even if the GNU tar does not support reading those attributes, it does handle them gracefully, warning the user of unknown extended headers, and then proceeding to unpack the data without preserving the extended attributes. So what Doug said stands perfectly and does not interest GNU tar at all. -- Diego Flameeyes Pettenò http://blog.flameeyes.eu/ pgpP94k0pAIHZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: lzma tarball usage
On Thursday 08 May 2008, Doug Goldstein wrote: Additionally to follow myself up, I believe one of the security issues was execution of arbitrary data either when untarred or just decompressed (assuming a specially crafted lzma file). Can you please point me to the location where this is mentioned. I read through the lzma git log, and I all I could find was data corruption (which usually is not a security issue) and the mention of the word security inside the announcement. Thanks, Robert signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: RFC: lzma tarball usage
On Thu, 08 May 2008 09:17:08 -0400 Doug Goldstein [EMAIL PROTECTED] wrote: Ryan Hill wrote: The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce According to the mailing list this change was done to fix security holes in the format and also resulted in a slightly different format that's incompatible with the previous verion. So lzma 5.x and higher will be a different on disk format. It's troubling to me that projects are using lzma when it's on disk format isn't even final and the project has security issues. The current format is fine. It's the new format that has design/security issues. Yes the formats are incompatible, but so are .tar.lzma and .7z, which are both lzma. Either way I was just offering it as a data point. I have no real opinion one way or the other. -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: lzma tarball usage
On Wed, 07 May 2008 16:23:12 +0300 Mart Raudsepp [EMAIL PROTECTED] wrote: Hello, Over the course of this year, a lzma-utils buildtime dependency has been added to a few system packages, to handle .tar.lzma tarballs. This has huge implications on the requirement of the system toolchain, which is highly disturbing from a minimal (lets say embedded) systems concern - lzma-utils depends on the C++ compiler and the libstdc++ beast, while a minimal system would like to avoid this at all cost. The new lzma-utils codebase uses liblzma, written in C. It's at the alpha stage but supposedly supports encoding/decoding the current lzma format well enough (;P). It probably has some fun bugs to find and squish. http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.orgforum_name=lzmautils-announce -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
