* Lucas Nussbaum <lu...@lucas-nussbaum.net>, 2009-08-11, 23:20:
* No upload since 2006No changes upstream since 2006, no bugs filed to fix.
How about #438045?
A strong point in favor of removing it is that we should not mislead users to software when a better alternative exists. Are there reasons/use cases where ssss would be better than libgfshare-bin?
- In my opinion, libgfshare has cumbersome user interface; on the other hand, you can easily use ssss in pipelines.
- I will never remember libgfshare name. ;)- libgfshare uses GF(256) fields, which imply that it needs to use some additional (undocumented!) means to deal with data more than 1 byte long. On the other hand, ssss can use GF(2**n) for n up to 1024 and it is documented how to work around 1024-bit limit.
However, for this particular package, it might make sense to keep providing it for a while, since removing it might cause users to lose the tool to recover their data.
Yes, I have some shared secrets generated by ssss and I want to be able to recover them once they are need. I don't really understand why do you want to remove a package which is in a relatively well shape.
Unless ssss-"encrypted" data is "decryptable" with libgfshare-bin?
It's not. -- Jakub Wilk
signature.asc
Description: Digital signature
