On Tue, Mar 15, 2011 at 01:36:32PM +0100, Milan Broz wrote: > On 03/15/2011 01:09 PM, Arno Wagner wrote: > > >> I will also limit LUKS keyfile in next version, mistake will cause problems > >> (reading the whole device in locked memory -> OOPS or something like that). > > > > Indeed. What you could do is have it default to error instead of > > to cut-down and proceed. That would make more sense, since > > cutting it is almost always not going to work. > > yup. This is common problem for all supported types, so I will probably > remove per-type limits, and add one maximal keyfile limit configurable > during compile time. > > Exceeding this limit will cause fail. > > Limiting keyfile read (if needed - like /dev/urandom or when stored > in the beginning of device) should be always possible using --keyfile-size > parameter (or --new-keyfile-size for new keyfile option). > > (This commadline limit option should possibly override maximal compiled-in > limit if specified number is larger.) > > Is it better approach? > > Milan Sounds fine to me, especially if the commandline can override the compile limit. Then the compile-limit protects everybody except those that think they know what they are doing. And those are responsible for their own actions. This would also remove any need to think about extreme cases in the compile limit. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
