[fossil-users] Question about MERGE

[tonyp]

Today I tried something and got an unexpected result.  So, I would like to know 
what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these 
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, I 
REVerted the files whose changes I did not want included yet (as they are not 
fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the rest 
of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?

Thanks.___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[tonyp]

OK, but doesn't cherry-pick work the same as a MERGE but only for single 
version of the timeline?


My intent was to get all changes from the branch (the whole history) but for 
specific files, only.


-Original Message- 
From: Richard Hipp

Sent: Wednesday, October 28, 2015 6:00 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Question about MERGE

On 10/28/15, to...@acm.org  wrote:

Today I tried something and got an unexpected result.  So, I would like to
know what the right way would have been.

I created a new branch and made a whole bunch of changes.  Some of these
changes were tested, and so I decided to merge them in to the trunk.

I did this by going to trunk, and the MERGE the other branch.  But, then, 
I

REVerted the files whose changes I did not want included yet (as they are
not fully tested).

I committed the result to the trunk.

Then I tried to merge that other branch again, and I expected to get the
rest of the files merged in.  But, instead I got a no-op error.

So, how could I have this correctly?



Cherry-pick the changes you wanted to import.

When you did "fossil merge" that told Fossil that your intent was that
everything in the branch had been integrated into the trunk.  You went
back and undid some of those changes using "fossil revert", but Fossil
understood that to be your intent - that you wanted to abandon those
changes.

--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[Richard Hipp]

On 10/28/15, to...@acm.org  wrote:
> Today I tried something and got an unexpected result.  So, I would like to
> know what the right way would have been.
>
> I created a new branch and made a whole bunch of changes.  Some of these
> changes were tested, and so I decided to merge them in to the trunk.
>
> I did this by going to trunk, and the MERGE the other branch.  But, then, I
> REVerted the files whose changes I did not want included yet (as they are
> not fully tested).
>
> I committed the result to the trunk.
>
> Then I tried to merge that other branch again, and I expected to get the
> rest of the files merged in.  But, instead I got a no-op error.
>
> So, how could I have this correctly?
>

Cherry-pick the changes you wanted to import.

When you did "fossil merge" that told Fossil that your intent was that
everything in the branch had been integrated into the trunk.  You went
back and undid some of those changes using "fossil revert", but Fossil
understood that to be your intent - that you wanted to abandon those
changes.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[bch]

On 10/28/15, Richard Hipp  wrote:
> On 10/28/15, to...@acm.org  wrote:
>> OK, but doesn't cherry-pick work the same as a MERGE but only for single
>> version of the timeline?
>>
>> My intent was to get all changes from the branch (the whole history) but
>> for
>>
>
> Fossil does not currently support the ability to merge some files but
> not others.  That has never come up before.

I've certainly wished for the NOP operation that looks to be a side
effect of the [merge]/[revert] (and a cause of concern/confusion for
Tony). I tried to describe this to you years (6?) ago (without
success), but now I see I can get an effect of my original wish this
way... I'll see if I can dig out my original problem/paradigm, in case
it's enlightening.

-bch


>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[Richard Hipp]

On 10/28/15, to...@acm.org  wrote:
> OK, but doesn't cherry-pick work the same as a MERGE but only for single
> version of the timeline?
>
> My intent was to get all changes from the branch (the whole history) but for
>

Fossil does not currently support the ability to merge some files but
not others.  That has never come up before.


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] SHA1 and security

[Scott Robison]

On Wed, Oct 28, 2015 at 6:37 PM, Eduard 
wrote:

> Hi,
>
> I wish to discuss the issues surrounding the use of SHA1 in Fossil and
> their consequences, as well as propose several possibilities to deal
> with them.
>

{whole bunch of snipped stuff}

If fossil didn't say it used SHA1 to generate artifact IDs, I don't think
anyone would care how it generated IDs.

An artifact ID is a way of assigning a fixed length identifier to an
artifact with good distribution of IDs in the fixed length space provided.
It is not intended to be a cryptographic.

You can't create a collision in advance based on not knowing who is going
to commit what to the repository in advance.

Let's say you do, after the fact, manage to create a collision. If you try
to upload it to the repository it will be ignored because fossil believes
(correctly) it already has the artifact in question.

As you observe, one could in theory mount a MITM attack. At this point what
is to stop them from serving a completely alien repository that they've
specially crafted? No collisions required.

In fact, the "easiest" way to getting people to use malicious software is
to host a compromised repository and convince people to use it instead of
the "blessed" repository.

If you want to change the way fossil does things to limit the possibility
of fraudulent artifacts, that's fine. Perhaps prefixing the blob data with
a length (ala git) might help mitigate the possibility of hash collisions.
Perhaps creating a hash of the complete commit (vs just the manifest) and
storing it in the manifest might help.

Ultimately, one can chase hash algorithms forever trying to create some
ultimately secure ideal. In the case of actual security software, I can see
the point. In this case, it's just an identifier, and the odds of a
non-malicious collision are so close to zero that those odds might as well
be zero.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Question about MERGE

[Matt Welland]

This is a surprisingly frequent need. Fossil is designed around a "get
things right the first time" philosophy but real life is often not that
crisp and clean. Being able to gracefully recover from mistakes and then
get rid of the irrelevant leftover cruft would be a wonderful addition to
fossil. I've used a methodology roughly like the following to handle this
kind of scenario:

define change-a as your single checkin containing two distinct changes
define change-a1 as part one of your two changes in change-a
define change-a2 as part two of your two changes in change-a

1. check out the common ancestor node
2. use meld or "fossil cat -r somever somefile > somefile" etc. to pull
change-a1
3. commit the change to a new branch change-a1-branch
4. repeat steps 1-3 for change-a2 creating change-a2-branch
5. close the change-a branch leaf, maybe hide it
6. create new branch change-a by merging change-a1 and change-a2
7. merge change-a1 to where they are needed

This is harder to describe than to do :)


On Wed, Oct 28, 2015 at 11:52 AM, bch  wrote:

> On 10/28/15, Richard Hipp  wrote:
> > On 10/28/15, to...@acm.org  wrote:
> >> OK, but doesn't cherry-pick work the same as a MERGE but only for single
> >> version of the timeline?
> >>
> >> My intent was to get all changes from the branch (the whole history) but
> >> for
> >>
> >
> > Fossil does not currently support the ability to merge some files but
> > not others.  That has never come up before.
>
> I've certainly wished for the NOP operation that looks to be a side
> effect of the [merge]/[revert] (and a cause of concern/confusion for
> Tony). I tried to describe this to you years (6?) ago (without
> success), but now I see I can get an effect of my original wish this
> way... I'll see if I can dig out my original problem/paradigm, in case
> it's enlightening.
>
> -bch
>
>
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > ___
> > fossil-users mailing list
> > fossil-users@lists.fossil-scm.org
> > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> >
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] SHA1 and security

[Eduard]

Hi,

I wish to discuss the issues surrounding the use of SHA1 in Fossil and
their consequences, as well as propose several possibilities to deal
with them.

I would like to take a moment to define collision resistance and
second-preimage resistance. A hash H is collision-resistant if it is
infeasible to come up with x1 and x2 such that H(x1)=H(x2). A hash H is
second-preimage resistant if given some x1, it is infeasible to come up
with x2 such that H(x1)=H(x2). Of course, collision resistance implies
second-preimage resistance (but not the other way around).

First I propose that the use of SHA1 in Fossil is a serious problem.
Even if no second-preimage attack is ever successful against it, a
collision attack is currently considered possible (although expensive) [1].

How much damage can be done given the capacity to generate collisions?
Suppose the attacker generates two versions of file "main.c" that share
the same SHA1 hash, one which is malicious ("main-malicious.c") and one
which is clean ("main-clean.c"). If the attacker can intercept
communications between the server and a developer, the attacker can push
"main-malicious.c" to the server, intercept the sync between the server
and developer and substitute "main-clean.c" for "main-malicious.c", then
wait until the developer tags and/or signs the change. Moreover, it will
appear as if the developer has PGP signed the malicious version!

If the attacker is in control of the server, then this becomes even
easier; push the clean version, tell the developer to tag/sign/approve
their checkin, then shun the clean version and replace it with the
malicious one.

If a project is hosted on multiple mirrors that periodically sync with
each other and the attacker knows that the main developer tends to use
only one of them, the attacker can push the clean version to the mirror
that is used by the main developer, and simultaneously push the
malicious one to the other servers.

These concerns are only amplified as the price of generating full SHA1
collisions drops (by further cryptanalytic advancement or by
technological improvements in computing).

Hoping that I have convinced you that this is a serious problem, I would
like to discuss the ways to tackle it.

The first solution is to do nothing and just tell users not to sync with
untrusted repositories. Given the distributed nature of software (and
otherwise) development, I believe it is a difficult burden to impose
upon developers that all contributors always be carefully vetted, and
that third-party (web) hosting never be trusted. I feel that this also
breaks the "eternally incorruptible" promise of Fossil.

The second solution is to incompatibly change the Fossil specification
and replace SHA1 hashes with BetterHash (for some value of BetterHash;
discussion below) in the definition of an artifact ID. This is a
*breaking* change, and requires the *modification* of artifacts (which I
believe is frowned upon in the fossil community to say the least). This
would break older hyperlinks (which would be easy to fix automatically
just by replacement when porting the artifacts to the new format), and
most definitely breaks older PGP clearsigned checkins (which would have
remained secure as long as SHA1 second-preimage attacks are infeasible).
The main advantage to this approach is that it is the most elegant and
easy to understand and deal with. The main disadvantage is that porting
artifacts to the new format requires their modification (which breaks
the "artifacts never change" promise; I would like to note that that
promise would also be broken as soon as an attacker inserts an artifact
for which a SHA1 collision is known).

The third solution is to change the Fossil specification to redefine the
artifact ID to be the concatenation of the SHA1 and BetterHash hash
digests, and allow 40 hexadecimal digit IDs as prefixes. One can show
that the preimage- and collision-resistance of this combination is at
least as good as the strongest of the two. The main advantage of this
approach is that it is not a breaking change, and does not require the
modification of older artifacts (hyperlinks stay the same too). The main
disadvantage is that if SHA1 preimages become feasible, an attacker can
definitely go back and mess with the pre-change SHA1-only artifacts (and
thus corrupt repositories, or worse). Another disadvantage is that the
SHA1 part of the ID takes up extra room and extra computing time with no
benefit in security.

As for the exact value of BetterHash, I would like to nominate
BLAKE2b-512 [2]. It is faster than both MD5 and SHA1, it is based upon
BLAKE which has received a lot of cryptanalytic attention during the
SHA3 competition, and it retains a large security margin (the best
(academic) attack to date is on a reduced version that does only 2.5
rounds instead of 10, and even then only downgrades the security from
512 to 481 bits).

Please let me know your thoughts on this matter.

Best regards,
Eduard

[1]