Hi, > One thing that the two failures had in common is that component x.000 was > produced and was used to remake the share; with the default 3-of-5 setting, > this can be expected to happen in around 2% of calls to gfsplit.
That indeed seems to fit my observations. > The mathematics of Shamir secret sharing do not work correctly with x_i = 0, > i.e. a component foo.000, so the library should reject any sharenrs array > that contains 0, and the utilities should not produce such arrays. I'll > prepare a patch this evening. Why is it "randomized" anyhow? Just numbering shares from 1 would produce more reproducible results, thus making it more likely that problems specific to a certain use case would get noticed before it's too late. It probably would be easier to use for some purposes, too, if file names were easier to predict. BTW, the command line parser is pretty much completely broken if you judge it by the error messages it produces even for completely valid values as per its own help output. In case you want to fix that, too ... Florian -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
