On Tue, Sep 15, 2015 at 8:28 AM, Scott Doctor wrote:
>
> What are the items that are used to calculate the hash? Is the hash salted?
For files/blobs, only their content is hashed (their name/timestamp/etc.,
if any, is not used). No salt is used. If i'm not mistaken (but might be),
a salt is irr
What are the items that are used to calculate the hash? Is the
hash salted?
Scott Doctor
sc...@scottdoctor.com
--
On 9/14/2015 10:53 PM, Stephan Beal wrote:
On Mon, Sep 14, 2015 at 7:46 PM, Warren Young
mailto:w...@etr-usa.com>> wrote:
output, and Fossil wo
On Mon, Sep 14, 2015 at 7:46 PM, Warren Young wrote:
> output, and Fossil would be free to switch to a different algorithm later
> if that seemed like a good idea.
>
Indeed, fossil's model allows any hash to be used, but it is not possible
to change the hash without a near-complete overhaul of f
On Sep 14, 2015, at 4:40 PM, Warren Young wrote:
>
> glibc-based Linux systems cope with this problem in /etc/shadow by tagging
> the hash
I just learned that this isn’t a Linux-specific thing, that it is in fact a
pseudostandard also used on the BSDs and in various other places:
http://pyt
On Sep 14, 2015, at 4:24 PM, Ron W wrote:
>
> On Mon, Sep 14, 2015 at 1:46 PM, Warren Young wrote:
>
> > What would be gained is that people wouldn’t be trying to work out how to
> > match sha1sum commands to Fossil output,
>
> fossil artifact id | sha1sum -
> sha1sum path/to/file
See, that
On Mon, Sep 14, 2015 at 1:46 PM, Warren Young wrote:
> The question is, “Why does this UI web page have to *say* that it is a
> SHA-1 hash?”
>
> If this page just said “checkin ID,” what would be lost?
>
As far as VCS functionality, nothing.
On the other hand, many projects publish the hashes f
On Mon, Sep 14, 2015 at 3:10 PM, Scott Robison
wrote:
>
> I wasn't really thinking of who might want to do it, just that sha1 isn't
> being used for cryptographic security and that would be covered by other
> means (GPG for example).
>
The hashes can be important for verifying the integrity of th
On Mon, Sep 14, 2015 at 1:01 PM, Warren Young wrote:
> On Sep 14, 2015, at 12:11 PM, Scott Robison
> wrote:
> >
> > > Fossil would be free to switch to a different algorithm later if that
> seemed like a good idea.
> >
> > Is this really a problem? Given that the checkin ID is generated from a
>
On Sep 14, 2015, at 12:11 PM, Scott Robison wrote:
>
> > Fossil would be free to switch to a different algorithm later if that
> > seemed like a good idea.
>
> Is this really a problem? Given that the checkin ID is generated from a
> structured manifest file which is generated in part from sha
On Mon, Sep 14, 2015 at 11:46 AM, Warren Young wrote:
> On Sep 12, 2015, at 2:26 AM, Stephan Beal wrote:
> >
> > On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote:
> > For instance, why even mention “SHA1 Hash” on the checkin details page
> in fossil ui, from src/info.c? Why not something m
On Sep 12, 2015, at 9:54 AM, Oliver Friedrich
wrote:
>
> with nested repositories my administration overhead would exceed even the
> single repository solution, right?
The alternative to managing just one .fossil file is managing just one directly
full of .fossil files. Is that really such a
On Sep 12, 2015, at 2:26 AM, Stephan Beal wrote:
>
> On Sat, Sep 12, 2015 at 12:57 AM, Warren Young wrote:
> For instance, why even mention “SHA1 Hash” on the checkin details page in
> fossil ui, from src/info.c? Why not something more generic, like “checkin
> ID”?
>
> The checkin ID is the
See the transcript below for gory details. The summary is:
1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so
cherrypick it (assume in this example that other stuff
13 matches
Mail list logo
