Skip to content

Conversation

@cmb69
Copy link
Member

@cmb69 cmb69 commented Mar 5, 2021

As already elaborated in my comment on the ticket[1] this issue cannot
be fixed in any stable version due to the ABI break.

Thus, this patch adds an optional $password parameter to ::getStream(),
so that users can retrieve streams of encrypted files in the archive.
This also works for files with individual passwords (i.e. not using the
general password of the archive), as can be seen in the accompanying
test case.

[1] https://bugs.php.net/80833#1614950012

As already elaborated in my comment on the ticket[1] this issue cannot
be fixed in any stable version due to the ABI break.

Thus, this patch adds an optional $password parameter to ::getStream(),
so that users can retrieve streams of encrypted files in the archive.
This also works for files with individual passwords (i.e. not using the
general password of the archive), as can be seen in the accompanying
test case.

[1] <https://bugs.php.net/80833#1614950012>
@cmb69
Copy link
Member Author

cmb69 commented Mar 5, 2021

Note that even if we're postponing the fix to "master" and going to store the default password in the ZipArchive object, adding the optional password parameter to ::getStream() would still make sense for file passwords.

@remicollet, thoughts?

@cmb69
Copy link
Member Author

cmb69 commented Mar 16, 2021

Any thoughts how to proceed here?

}

if (password != NULL) {
if (zip_set_default_password(stream_za, password) != 0) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it make more sense to use zip_fopen_encrypted, rather than using zip_set_default_password for a single file?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zip_fopen_encrypted() is only available as of libzip 1.0.0, but even "master" still supports libzip ≥ 0.11. :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, then this implementation makes sense...

@nikic
Copy link
Member

nikic commented Aug 11, 2021

Not really sure about this, would be good if @remicollet takes a look.

I think the important thing to address is to make use of the password set by setPassword() -- if we can only do that in master, so be it.

Having this as additional functionality still makes sense for file passwords, but I think that would need some more general support. In particular, this allows passing a file password to getStream(), but wouldn't it also make sense for getFromName() and getFromIndex(), which return a string rather than stream?

@remicollet
Copy link
Member

I need to think more about this...
IMHO should go in a stream context, and is already implemented

$o = [
	'zip' => [
		'password' => "file_password",
	],
];

$c = stream_context_create($o);
var_dump(file_get_contents("zip://" . __DIR__ . "/80833.zip#test.txt", false, $c));

So this is only about the getStream method.... seems a buggy one...

@cmb69
Copy link
Member Author

cmb69 commented Aug 11, 2021

IMHO should go in a stream context, and is already implemented

That's great for single files, but not so when you need to read multiple files from the same archive, which have different passwords. On the other hand, such archives might be very rare.

@remicollet
Copy link
Member

IMHO should go in a stream context, and is already implemented

That's great for single files, but not so when you need to read multiple files from the same archive,

Yes, just searching why this doesn't work for getStream, so why we have 2 really different implementation to open a stream with different behavior

@remicollet
Copy link
Member

Found explanation.

On getStream call, the same archive is open again, thus loosing the password.

See PR #7359 which use the same zip object, which seems better for performance, and also fix this issue.
Also suitable for 7.4+

@cmb69
Copy link
Member Author

cmb69 commented Sep 1, 2021

Closing in favor of PR #7359.

@cmb69 cmb69 closed this Sep 1, 2021
@cmb69 cmb69 deleted the cmb/80833 branch September 1, 2021 11:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants