| 1 |
On Thu, 08 May 2008 09:17:08 -0400 |
| 2 |
Doug Goldstein <cardoe@g.o> wrote: |
| 3 |
|
| 4 |
> Ryan Hill wrote: |
| 5 |
> > The new lzma-utils codebase uses liblzma, written in C. It's at the |
| 6 |
> > alpha stage but supposedly supports encoding/decoding the current |
| 7 |
> > lzma format "well enough" (;P). It probably has some fun bugs to |
| 8 |
> > find and squish. |
| 9 |
> > |
| 10 |
> > http://sf.net/mailarchive/forum.php?thread_name=200804251652.58484.lasse.collin%40tukaani.org&forum_name=lzmautils-announce |
| 11 |
|
| 12 |
> According to the mailing list this change was done to fix security |
| 13 |
> holes in the format and also resulted in a slightly different format |
| 14 |
> that's incompatible with the previous verion. So lzma 5.x and higher |
| 15 |
> will be a different on disk format. It's troubling to me that |
| 16 |
> projects are using lzma when it's on disk format isn't even final and |
| 17 |
> the project has security issues. |
| 18 |
|
| 19 |
The current format is fine. It's the new format that has |
| 20 |
design/security issues. Yes the formats are incompatible, but so |
| 21 |
are .tar.lzma and .7z, which are both lzma. Either way I was just |
| 22 |
offering it as a data point. I have no real opinion one way or the |
| 23 |
other. |
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
fonts, gcc-porting, by design, by neglect |
| 28 |
mips, treecleaner, for a fact or just for effect |
| 29 |
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 |
Archives