I think a number of applications use a concatenation of a standard archive
format and custom data. The most well known probably is .rpm which is/was a
cpio stream immediately followed by additional information (iirc - it might
go the other way). In any case a developer might expect to have the inpu
Hi, I know that the implementation of the PKWARE AES crypto is subject to
license restrictions but is it possible to recognize the extension fields
so anyone scanning an unfamiliar file will at least know what the extra
field headers contain?
I don't know if code to parse the contents (solely usin
y're quietly handled by the default handler.
- one unit test blows up due to missing central directory (it's encrypted).
I guess the next step is either finding a way to have the unit tests
trigger reading the extra headers or confirm that it's not possible.
Bear
On Wed, Sep 2, 2015
ago...)
Bear
On Thu, Sep 3, 2015 at 10:12 PM, Bear Giles wrote:
> I've forked at github.com/beargiles/commons-compress and committed some
> initial work - five new ExtraHeader classes, their registration, two test
> files and four unit tests.
>
> One test file uses certif
e headers. It's
enough to identify the encryption and hash algorithms used but a lot is
left unparsed.
Bear
On Fri, Sep 4, 2015 at 12:17 PM, Bear Giles wrote:
> I just came across a press release that suggests that it is possible to
> support AES encryption for zip files:
>
>
fan Bodewig wrote:
> Hi Bear
>
> sorry for the late reply. My spare time is currently severly limited
> but this should be getting better by the end of the month.
>
> On 2015-09-05, Bear Giles wrote:
>
> > I was just reminded of the risks of making assumptions. Th
ally you can do a pull request. I think.
Bear
On Tue, Sep 15, 2015 at 8:03 AM, Stefan Bodewig wrote:
> On 2015-09-14, Bear Giles wrote:
>
> > I want to capture as much information as possible but the documentation
> is
> > a weird mixture of details and hand-waving. Some
oken this way. Messages
were supposed to start with a unique value but one clerk repeated one by
accident. It was enough to break the cipher since all messages started the
same way.
Bear
On Sun, Sep 20, 2015 at 8:36 PM, Bear Giles wrote:
> I took out some debugging scaffolding so you can check
I'm still unclear on the final mile of a submission. I think I've properly
merged everything upstream and submitted a pull request for my work but I
wouldn't put much money on that bet. Let me know if there's problems - it
should only be a half-dozen files or so.
Also I can't build locally due t
1. I created the PKWareExtraHeader as a marker - it should make it clear
that the headers will only be present in PKWare-created files and everyone
else can ignore them. This is in contract to other headers that are much
more standard. It was an oversight if this got lost when I had to refork
the p
In case you're talking about my test data the uncompressed test case could
be externally compressed and the test code adjusted accordingly. It never
occurred to me to do that since you never compress dump files like that in
the wild - you use the native compression instead - but the file is almost
if things go wrong. (I know, people can get the
source and compile it themselves but it will take time to track down the
problem, identify a solution, etc.)
Is this something worth addressing now or should it wait until 2.0?
Bear Giles
On Sun, Oct 30, 2011 at 7:38 PM, Gary Gregory wrote:
>
argue that the code would be cleaner if we (explicitly) let the
InputStream method handle bad parameters or it will be cleaner if we
explicitly check for null or short buffers or if we do a mixture.
On Mon, Oct 31, 2011 at 2:59 PM, Bear Giles wrote:
> I found a few issues (1330) with Forti
What is the status on strong encryption in zip files? That is - I know we
don't have it, but is there a reason why it hasn't been added or is it just
an itch that hasn't been scratched?
I can see several levels of values
1. add ZipExtraField handlers for the five extra fields of interest (0x14,
0
This morning I realized that the license requirement could be a real
problem if it applies to the end developer instead of or in addition to any
libraries. On the other hand it might just be a completely reasonable
requirement that the code be tested for compatibility with PKWARE and the
license re
y mentioned but providing strong encryption
> > causes administrative head-ache
> >
> > http://www.apache.org/dev/**crypto.html<
> http://www.apache.org/dev/crypto.html>
> >
> > Cheers,
> >
> > Siegfried Goeschl
> >
> > On 12.06.1
What would be the best way to start pushing code? It will be more tightly
integrated with the existing code than my earlier 'dump' contribution so I
can't just dump a source ball. I also don't want to post code snippets here
if it will cause people problems.
Thanks,
Bear
On Thu, Jun 13, 2013 at
Would that trigger the 'export' clause?
The main deliverable I hope to have in the next few days is a method for
password-based decryption that will be called at the end of getNextEntry().
It looks like it will take a Cipher initialized by the master password and
provide either a Cipher initialize
Should that be PKCS7Padding? Or would that be worse - I don't recall if
it's one of the "must have" paddings in the spec.
http://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding
In practice it's unlikely that a software-based crypto provider w
We discussed adding support for the traditional zip encryption algorithm a
while back. IIRC the concensus was loosely against it since it's so weak
and we don't want to mislead people.
Since then I can add two points.
First, I heard from someone who said that she has to use the traditional
encryp
/archivers/zip/TraditionalZipEncryptionTest.java
Bear
On Tue, Feb 16, 2016 at 9:08 AM, Stefan Bodewig wrote:
> On 2016-02-15, Bear Giles wrote:
>
> > We discussed adding support for the traditional zip encryption algorithm
> a
> > while back. IIRC the concensus was l
I've been looking at the strong crypto side of it. I have a test file but the
published spec is vague at times (unless you are in windows and can use their
crypto library), not a huge hurdle but I've been busy. I should at least submit
a patch that recognizes the four addl block types even if we
I'm bummed. One of my interview torture questions was whether this compiles.
class _ {
static _ _ ;
_() {
}
_(_ _) {
}
}
On Thu, Apr 3, 2014 at 6:44 AM, Stefan Bodewig wrote:
> On 2014-04-03, Emmanuel Bourg wrote:
>
> >
> http://openjdk.5641.n7.nabble.com/Warning-about-single-undersc
23 matches
Mail list logo
