A NOTE has been added to this issue. 
====================================================================== 
https://www.austingroupbugs.net/view.php?id=1827 
====================================================================== 
Reported By:                nrk
Assigned To:                
====================================================================== 
Project:                    Issue 8 drafts
Issue ID:                   1827
Category:                   Shell and Utilities
Type:                       Enhancement Request
Severity:                   Objection
Priority:                   normal
Status:                     New
Name:                       NRK 
Organization:                
User Reference:              
Section:                    compress(1) utility 
Page Number:                n/a 
Line Number:                n/a 
Final Accepted Text:         
====================================================================== 
Date Submitted:             2024-04-15 03:23 UTC
Last Modified:              2024-04-16 23:03 UTC
====================================================================== 
Summary:                    Standardize gzip(1) cli interface instead of adding
it to compress(1)
====================================================================== 

---------------------------------------------------------------------- 
 (0006755) nrk (reporter) - 2024-04-16 23:03
 https://www.austingroupbugs.net/view.php?id=1827#c6755 
---------------------------------------------------------------------- 
> a new compression format should be added.

zstd is nice and I do like it. But IMO this is off-topic for this issue
which is more regarding compress(1) and gzip(1).

> Regarding checksums [...] Blake2

Are we talking about checksum utilities or the checksum present in the
compressed archive?

I view both as off-topic for this issue, but if it's the latter then I'd
like to point out that using a cryptographic hash as checksum in compressed
archive has *no security benefits*. If an attacker can modify the
compressed data stream then he can also modify the hash which is stored in
the same file.

Lzip's choice of CRC32 is a perfectly fine decision to detect non-malicious
data corruptions. If you want to detect malicious modification then the
hash needs to be stored elsewhere outside the attacker's control. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2024-04-15 03:23 nrk            New Issue                                    
2024-04-15 03:23 nrk            Name                      => NRK             
2024-04-15 03:23 nrk            Section                   => compress(1) utility
2024-04-15 03:23 nrk            Page Number               => n/a             
2024-04-15 03:23 nrk            Line Number               => n/a             
2024-04-15 03:24 nrk            Issue Monitored: nrk                         
2024-04-16 05:57 dannyniu       Note Added: 0006752                          
2024-04-16 05:58 dannyniu       Note Edited: 0006752                         
2024-04-16 18:39 steffen        Note Added: 0006753                          
2024-04-16 22:51 nrk            Note Added: 0006754                          
2024-04-16 23:03 nrk            Note Added: 0006755                          
======================================================================


  • [Issue 8 dra... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [Issue ... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to