quot; INCREMENT BY 1 MINVALUE
0 NO MAXVALUE CACHE 1;") from {}' >migration_ddls_part2.sql
Would it make sense to detail the migration path a little more in
https://raw.githubusercontent.com/openxpki/openxpki-config/community/UPGRADEv3.md?
I could open a Pull Request, if that makes sense.
Regards,
Dirk
A
("DROP TABLE {}; CREATE SEQUENCE
{} START WITH ", ifnull(max(seq_number),0), " INCREMENT BY 1 MINVALUE 0
NO MAXVALUE CACHE 1;") from {}'
--
aiticon GmbH
Dirk Heuvels
Stephanstraße 1
60313 Frankfurt am Main
t. +49 69 795 83 83-0
f. +49 69 795 83 83-28
dirk.heuv...@aiti
there a risk of breaking things, if I simply
remove the check from the workflow? If it only results in the
(theoretical) possibility to craft certificates for the same key, I can
live with it.
Cheers,
Dirk
Mit freundlichen Grüßen,
Dirk Heuvels
--
aiticon GmbH
Dirk Heuvels
Stephanstraße 1
60313 Fra
ache session does
not really make sense from a business view so I think we will fix the problem
by removing the "clear" button.
I will add a ticket to get the secret handling reworked for one of the next
releases.
best regards
Oliver
Am 01.12.2017 um 09:39 schrieb Dirk Heuvels
[OpenXPKI-users] Secret group session error after update from 1.17
to 1.19
Hi Dirk,
have a look at this Pull Request if you want to patch it by yourself
https://github.com/openxpki/openxpki/pull/594/files
I will also create new packages (v.1.19.5)
Oliver
Am 21.11.2017 um 10:39 schrieb Dirk Heuvel
Hi Oliver,
I applied the patch and it's working again.
Thank you very much for your assistance,
Dirk
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/s
Hi everyone,
I have been using OpenXPKI 1.17 on Debian Jessie as issuing CA and recently
updated to 1.19.4.
Since then my default secret group (realm.ca-one.crypto.secret.default) cannot
be cached in the session anymore.
The crucial setting in crypto.yaml:
secret:
default:
label: Defa
