-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug]: hash_hkdf(): Argument #2 ($key) cannot be empty #34012
Comments
Do you have a |
@solracsf Thank you, it seems that the parameter got lost somehow during one of the last couple of updates. I've now added the parameter again and will report if the error reappears again. |
If secret is missing, you will see this error. Once you add it back, it should work again. Please reopen this issue if it happens again after adding the secret parameter |
@CarlSchwan The problem seems to be more complex than I expected at the beginning. I found out that the
Next I've provided a value to the secret parameter to get rid of the reported messages. As expected this had a bigger impact on the server because all application passwords and mount passwords hd to be changed. I tried to get this done and was able to successfully set new app passwords but I was unable to access my personal external storage anymore. As soon as I access the external storage configuration page I get an exception displayed on the screen with the recommendation to check the server log file. |
#31499 is working and you can apply the patch. The reason why it is wip is that we wanted to have a migration step in the background adding the secret if it was missing :( I'll try to revive the branches |
@CarlSchwan Unfortunately I've already fixed the problem on my server. After setting the 'secret' parameter in the configuration I truncated the `oc_storages_credentials' table, which allowed me to access the external storage settings again and to enter new credentials. After that I had to set all application passwords again because the previously generated once didn't work anymore. Additionally I had to reconnect the TOTP applications of my users again. Finally I had to drop all mail tables and reinstalled the mail app to get it up-and-running again. For now it seems to work. Nevertheless the provided patch will be the right way to go, because otherwise many systems will most likely left in an insecure state. |
I merged the related PR |
This comment was marked as duplicate.
This comment was marked as duplicate.
same problem here |
Hello, |
I found a temporary solution. In the exception part, put $secret instead of empty ''. After the change, the code should look like this: |
Thank you! apparently it works quite well! |
This comment was marked as resolved.
This comment was marked as resolved.
I don't know if it is linked or not, but I am facing the same error when I click on external storages:
|
About HMAC there is a report at #32258 |
In version 27.0.0 there is still this issue. However, Crypto.php changed and now you should apply #34012 (comment) to line 132 You should have: /**
* Decrypts a value and verifies the HMAC (Encrypt-Then-Mac)
* @param string $authenticatedCiphertext
* @param string $password Password to encrypt, if not specified the secret from config.php will be taken
* @return string plaintext
* @throws Exception If the HMAC does not match
* @throws Exception If the decryption failed
*/
public function decrypt(string $authenticatedCiphertext, string $password = ''): string {
$secret = $this->config->getSystemValue('secret');
try {
if ($password === '') {
return $this->decryptWithoutSecret($authenticatedCiphertext, $secret);
}
return $this->decryptWithoutSecret($authenticatedCiphertext, $password);
} catch (Exception $e) {
if ($password === $secret) {
// Retry with empty secret as a fallback for instances where the secret might not have been set by accident
return $this->decryptWithoutSecret($authenticatedCiphertext, '');
}
throw $e;
}
} I will not commit a patch as I do not have studied the full implications of this change, but please have a look! |
I confirm the issue and the solution in #34012 (comment) for version 26.0.0 |
I have the same issue opening externalstorages in the administration panel for nectcloud
First I've checked my config.php to have a non-empty secret set.
After manually applying the change proposed here #34012 (comment) i do get the issue #32258 when opening the externalstorages panel.
@solracsf @denics as the the proposed solution #34012 (comment) does yield another issue #32258
Thanks |
It needs to be the same as the original if you migrated your server in the past. |
If I cannot find the original secret, how could I reset? What kind of data will be lost? |
I have exactly same issue with Nextcloud 27 from Truescale (TrueNAS scale) |
Still the same error in NC 28.0.1 and still the same solution #34012 (comment) |
IS this the same as #42157 |
Solution provided, didn't help for me. Problem still exists |
The same for me, I even transferred the old values (passwordsalt, secret) from the previous installation into the config.php, but the issue is still the same, Nextcloud 28.0.1.1 Strangely enough, I can access all of my data both via the Android app and via the web. That's why I don't really care. The only question is whether it is relevant to safety? |
Same here 28.0.2 |
I used it in Nextcloud 28.0.2 and I have to say it no longer shows nextcloud.log errors, it works very well. I also have to say that the issue only occurred when I was doing activities with the Android Nextcloud.app, everything else like different browser connections or Windows Nextcloud.app and Linux Nextcloud.app didn't cause this error. Thanks @denics |
@szaimen could you push for this fix amongst the core devs, or is it more complicated than that? (#34012 (comment)) |
Unfortunately I cannot tell. Pinging @nextcloud/server-backend for help on this |
This solution is hiding the problem instead of fixing it. \OCP\Server:get(\Psr\Log\LoggerInterface::class)->error('Decryption failed: '.$e->getMessage(), ['exception' => $e]); At the beginning of the catch of the decrypt method in Crypto.php. |
@come-nc you motivated me to activate the original crypto.php, strangely enough, there are no more errors in the nextcloud.log when I connect to the server with the android nextcloud.app, I also restarted the server. I'm not a developer but the behavior is somehow mysterious? |
Code works in mysterious ways 🪄🎩 |
Seems strange but injecting the code into Line 107 seems to have cured the issue... |
Ok, so shouldn't this line be in master? I mean since it provides useful info it might be a good idea? |
To be clear, from my understanding of the issue and the code, this can only be triggered by invalid encrypted data, most likely old encrypted data from previous versions of Nextcloud.
Yeah we could try to improve the error report for this case, not with this line directly I think. |
Still the same error in NC 28.0.5 and still the same solution #34012 |
There are different code paths to these situation. Full stack traces and history of your instance are important. At a high level, there are basically two ways to get this error:
In some cases, this isn't a bug and is expected behavior:Only you know the history of your Nextcloud instance, but maybe you recognize one of these scenarios:
The original report was hitting this from the
|
public function encrypt(string $plaintext, string $password = ''): string { | |
if ($password === '') { | |
$password = $this->config->getSystemValueString('secret'); | |
} | |
$keyMaterial = hash_hkdf('sha512', $password); | |
$this->cipher->setPassword(substr($keyMaterial, 0, 32)); | |
$iv = \random_bytes($this->ivLength); | |
$this->cipher->setIV($iv); | |
/** @var string|false $encrypted */ | |
$encrypted = $this->cipher->encrypt($plaintext); | |
if ($encrypted === false) { | |
throw new Exception('Encrypting failed.'); | |
} | |
$ciphertext = bin2hex($encrypted); | |
$iv = bin2hex($iv); | |
$hmac = bin2hex($this->calculateHMAC($ciphertext.$iv, substr($keyMaterial, 32))); | |
return $ciphertext.'|'.$iv.'|'.$hmac.'|3'; | |
} |
That scenario can only happen when the secret
is empty.
There are only ~3 other stack traces provided in this entire issue by anyone else and all are are coming via the decrypt()
side of things, which is different from the original reporter.
(And they're not all reaching decrypt()
via the same paths either.)
Full stack traces from all reporters are important to even determine whether what you're encountering has the same underlying root cause or not
Some possibilities I can think:
- your
secret
is indeed empty right now in yourconfig.php
[in theory there is handling for this today but maybe we missed something] - your
secret
was empty at some point but now it isn't [in theory there was going to be handling for this as part of Add fallback routines for empty secret cases #31499 too I think but maybe not?] - some bug introduced via other code paths that reach here
But please think through the history of your instance as well since this may just be telling us your secret changed at some point because it got overlooked during a migration/restore
And even if it is a bug, the history may be relevant. Since reproducing this (outside of the scenarios it's expected behavior) is the ideal way to address things, if there is indeed a bug.
thanks @joshtrichards , very useful indeed and I think I am one of those with a |
Exactly. Also, if External Storage is somehow using old |
As in get back the previous one? Only from your
It somewhat depends on the state of your configuration today. If your situation is basically: "I'm not using Server-side Encryption and moved to a new server, but didn't transfer over my old Though, beware, this is a massive oversimplification on my part since there are other factors that impact your individual situation, since External Storage supports multiple authentication mechanisms and I've not thought through all the various combinations. I think should work for Username and password, Globally Credentials, User Entered, but not for either of the Log-in credentials mechanisms. For Log-in credentials, save in database you could probably toggle to a different mechanism, save things, then maybe switch back. Keep in mind I'm making an educated guess here: there are a lot of variations and as I said I haven't tested (nor reviewed) every potential path. EDIT: As an aside, since I'm looking over the code again right now anyway, the |
@joshtrichards I think the FR here is about creating an I would for sure appreciate if that was possible. I mean even if I keep backups for several years (yes I do), it would be nice with something like Such a command shouldn't be run easily though, but like a last resort if you messed up recently or a long time ago. |
I believe I have this issue, following a migration of Nextcloud from bare metal to docker that I did just over a year ago. The log alerts in 28 must have drawn my attention to the errors. I guess I copied elements of the |
This bug still persists in 29.0.4 (apache-docker) after a migration (from nginx-fmp-docker 29.0.4). In my case, it's related to external storage: The user's settings do not open, instead, there's an internal server error. What solved it for me was taking over the The migration (manual & more detailed manual) took me ~3hrs working out all file system chowns and chmods as well as appdata migration etc with only 1 user and pretty much only the default set of files (it was almost a fresh install, but I wanted to test migration). |
30.0.0 the same |
In my case, I migrated my server with an error to a new installation, importing the database from the old one, restoring the postgres volume, but I ended up leaving the new secret in the php config where I must adjust it in the database for everything to work again because I cannot use any sharing resource that comes with the error, update to version 30 did not solve it, any tips. |
Bug description
After upgrading my server from Nextcloud v24.0.4 to v24.0.5 and also upgrading to PHP8 (I don't know if this is of importance), the Nextcloud cron job generates the following error output:
Steps to reproduce
I don't know how to reproduce it at the moment but it seems to occur if notification should be send-out.
Expected behavior
Execute background job without running into an error condition.
Installation method
Community Manual installation with Archive
Operating system
No response
PHP engine version
PHP 8.0
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 22.2.3 to 22.2.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
.
Additional info
.
The text was updated successfully, but these errors were encountered: