| H A D | g_eli_key_cache.c | 9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
9d180439 Fri Aug 10 18:43:29 GMT 2012 Pawel Jakub Dawidek <pjd@FreeBSD.org> Always initialize sc_ekey, because as of r238116 it is always used.
If GELI provider was created on FreeBSD HEAD r238116 or later (but before this
change), it is using very weak keys and the data is not protected.
The bug was introduced on 4th July 2012.
One can verify if its provider was created with weak keys by running:
# geli dump <provider> | grep version
If the version is 7 and the system didn't include this fix when provider was
initialized, then the data has to be backed up, underlying provider overwritten
with random data, system upgraded and provider recreated.
Reported by: Fabian Keil <fk@fabiankeil.de>
Tested by: Fabian Keil <fk@fabiankeil.de>
Discussed with: so
MFC after: 3 days
|