On Thu, Feb 1, 2024 at 5:26 PM Daniel Sahlberg
wrote:
>
> Gentlemen,
>
> It seems you have both had your say in what flaws there has been in the
> process. Can we please leave this part of the discussion and continue on the
> technical issues? I'd hate for this discussion to turn to pie-throwing
Gentlemen,
It seems you have both had your say in what flaws there has been in the
process. Can we please leave this part of the discussion and continue on
the technical issues? I'd hate for this discussion to turn to pie-throwing
where someone in the end feel offended and leave the community. We
Daniel Sahlberg writes:
> As far as I understand, the point of multi-hash is to keep the WC format
> between versions (so older clients can continue to use the WC).
Just as a minor note, the working copies created using the implementation
on the `pristine-checksum-salt` branch don't multi-hash t
On 18.01.2024 08:43, Daniel Sahlberg wrote:
As far as I understand, the point of multi-hash is to keep the WC
format between versions (so older clients can continue to use the WC).
I need some help to understand how that would work in practice. Let's
say that 1.15 adds SHAABC, 1.16 adds SHAXYZ.
Daniel Shahaf writes:
> Procedurally, the long hiatus is counterproductive.
This reminds me that the substantive discussion of your veto ended with my
email from 8 Feb 2023 that had four direct questions to you and was left
without an answer:
``
> That's not how design discussions work.
licy.
>
> I would like to add another reason to think about a post-SHA1 future: I'm
> writing on mobile so I can't easily grep for things now, but could our
> dependencies eventually remove the SHA1 implementation? (I just saw
> something about removal of DSA from some famous lib
On Sat, Jan 13, 2024 at 3:56 PM Nathan Hartman
wrote:
> Pros: Future-proofing against the real and perceived brokenness of any
> hash types.
>
I meant to write:
Pros: Future-proofing against the real and perceived brokenness of any hash
types, or the deprecation and later removal of their imple
ous lib not too long ago. SHA1
could be next?)
When would SHA1 disappear? I don't know, but I consider it plausible to
happen in about 5 years.
If SHA1 is removed in the future, there will need to be a mad dash to
replace it. Or we'll have to add a new dependency to use an alternate
impl
7;t understand the way it is used and its
> ramifications). Making it possible to 'svn add' SHA-1 collisions is
> not it, I think.
>
I also agree with this.
>From what I remember of the dicsussions earlier there were concerns that a
changed file might go undetected if someone chang
On Fri, Jan 12, 2024 at 12:37 PM Daniel Shahaf wrote:
...
> Procedurally, the long hiatus is counterproductive. Neither kfogel nor
> I had the context in our heads, and the cache misses took their toll in
> tuits and in wallclock time. Furthermore, I have less spare time for
> dev@ discussions t
apache.org/mod_mbox/subversion-dev/202212.mbox/%3C904aded6-5ef0-4123-ade0-e23a3bb56726%40app.fastmail.com%3E
>>>> Date: Fri, 20 Jan 2023 12:15:24 +
>>>> From: Daniel Shahaf
>>>> To: dev@subversion.apache.org
>>>> Subject: Re: Switching from SHA1
On 04 Jan 2024, Daniel Shahaf wrote:
Acknowledging receipt. I'll reply substantively when I have the
time to swap in the context.
Thanks. Yeah, I went through the same context-swapping-in process
yesterday before posting!
Best regards,
-Karl
Evgeny's work is on this branch...
https://sv
Karl Fogel wrote on Wed, 03 Jan 2024 22:13 +00:00:
> On 01 Apr 2023, Evgeny Kotkov via dev wrote:
>>Daniel Shahaf writes:
>>
>>> What's the question or action item to/for me? Thanks.
>>
>>I'm afraid I don't fully understand your question. As you
>>probably remember, the change is blocked by your
On 01 Apr 2023, Evgeny Kotkov via dev wrote:
Daniel Shahaf writes:
What's the question or action item to/for me? Thanks.
I'm afraid I don't fully understand your question. As you
probably remember, the change is blocked by your veto. To my
knowledge, this veto hasn't been revoked as of no
Daniel Shahaf writes:
> What's the question or action item to/for me? Thanks.
I'm afraid I don't fully understand your question. As you probably remember,
the change is blocked by your veto. To my knowledge, this veto hasn't been
revoked as of now, and I simply mentioned that in my email. It
Evgeny Kotkov via dev wrote on Wed, 22 Mar 2023 15:23 +00:00:
> This change is still being blocked by a veto, but if danielsh changes his
> mind and if there won't be other objections, I'm ready to complete the few
> remaining bits and merge it to trunk.
What's the question or action item to/for m
Evgeny Kotkov writes:
> > Now, how hard would this be to actually implement?
>
> To have a more or less accurate estimate, I went ahead and prepared the
> first-cut implementation of an approach that makes the pristine checksum
> kind configurable in a working copy.
>
> The current implementation
Daniel Shahaf writes:
> Look, it's pretty simple. You said "We should do Y because it
> addresses X". You didn't explain why X needs to be addressed, didn't
> consider what alternatives there are to Y, didn't consider any cons that
> Y may have… and when people had questions, you just began to
Evgeny Kotkov via dev wrote on Sun, Jan 29, 2023 at 16:37:20 +0300:
> Daniel Shahaf writes:
>
> > > (I'm not saying that the above rules have to be used in this particular
> > > case
> > > and that a veto is invalid, but still thought it’s worth mentioning.)
> > >
> >
> > I vetoed the change be
Karl Fogel wrote on Mon, Jan 30, 2023 at 17:26:03 -0600:
> On 29 Jan 2023, Evgeny Kotkov via dev wrote:
> > I have *absolutely* no idea where "being railroaded through" comes
> > from. Really, it's a wrong way of portraying and thinking about the
> > events that have happened so far.
> >
> > Reit
reamy checkout/update that avoid
> such lookups by writing straight to the working file. However, some of
> the code paths still install the contents from the pristine store by hash.
> Examples include reverting a file, copying an unmodified file, switching
> a file with keywords, the men
On 31 Jan 2023, Daniel Shahaf wrote:
Karl Fogel wrote on Mon, 30 Jan 2023 23:26 +00:00:
Daniel, given what's in Evgeny's branch now, could you
summarize
your current technical objections if any?
Certainly, but I won't have time to do so today.
Oh, my gosh, I'd be the last person to ever com
Karl Fogel wrote on Mon, 30 Jan 2023 23:26 +00:00:
> Daniel, given what's in Evgeny's branch now, could you summarize
> your current technical objections if any?
Certainly, but I won't have time to do so today.
On 29 Jan 2023, Evgeny Kotkov via dev wrote:
I have *absolutely* no idea where "being railroaded through"
comes from.
Really, it's a wrong way of portraying and thinking about the
events that have
happened so far.
Reiterating over those events: I wrote an email containing my
thoughts
and expl
Daniel Shahaf writes:
> > (I'm not saying that the above rules have to be used in this particular case
> > and that a veto is invalid, but still thought it’s worth mentioning.)
> >
>
> I vetoed the change because it hadn't been designed on the dev@ list,
> had not garnered dev@'s consensus, and
with a hash lookup in the pristine store. This is more true for 1.14
than trunk, because in trunk we have the streamy checkout/update that avoid
such lookups by writing straight to the working file. However, some of
the code paths still install the contents from the pristine store by hash.
Examples in
Definitions of attacks:
1. Collision attack:
Given h(),
find x₁, x₂ such that h(x₁) == h(x₂).
2. Second preimage attack:
Given h() and x,
find x′ such that h(x) == h(x′).
3. First preimage attack:
Given h() and y,
find x such that h(x) == y.
4. Chosen prefix attack:
Given h
ame wc in a particular way.
That is, I'm not assuming "forgery" (which implies Mallory is involved).
Still, this is a potential data integrity issue with the new-in-1.15 wc
format, so we should address it before the release. What are our
options to address that? Switching to another
Daniel Shahaf writes:
> > I can complete the work on this branch and bring it to a production-ready
> > state, assuming there are no objections.
>
> Your assumption is counterfactual:
>
> https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C20230119152001.GA27446%40tarpaulin.sh
Replying to multiple parts of this thread...
On Sat, Jan 21, 2023 at 12:58 PM Karl Fogel wrote:
> *nod* This issue isn't important enough to me to continue the
> conversation -- I'd like for new hash algorithms to be possible,
> and I think Evgeny's work on it is worthwhile, but I don't feel
> ne
[ tl;dr: See last paragraph for a concrete question about ra_serf. ]
Karl Fogel wrote on Fri, 20 Jan 2023 17:18 +00:00:
> Yes. A hash is considered "broken" the moment security researches
> can generate a collision.
Consider the following uses of hash functions in our code:
- FSFS rep-cache us
[See below a proposal that libsvn_wc not use any fixed hash function.]
Martin Edgar Furter Rathod wrote on Sat, 21 Jan 2023 05:22 +00:00:
> On 20.01.23 22:48, Karl Fogel wrote:
>> On 20 Jan 2023, Nathan Hartman wrote:
>>> We already can't store files with identical SHA1 hashes, but AFAIK the
>>> o
To be clear, I wasn't vetoing changing the hash algorithm. I was
vetoing making a change without discussion. If there is discussion and
it results in consensus to change the algorithm, that'll be absolutely
fine by me.
Daniel
Karl Fogel wrote on Sat, 21 Jan 2023 17:58 +00:00:
> *nod* This issue
*nod* This issue isn't important enough to me to continue the
conversation -- I'd like for new hash algorithms to be possible,
and I think Evgeny's work on it is worthwhile, but I don't feel
nearly as strongly about this as I feel about making the new
pristineless working copies available in an
Karl Fogel wrote on Fri, Jan 20, 2023 at 11:18:56 -0600:
> On 20 Jan 2023, Nathan Hartman wrote:
> > Taking a step back, this discussion started because pristine-free WCs
> > are IIUC more dependent on comparing hashes than pristineful WCs, and
> > therefore a hash collision could have more impact
Karl Fogel wrote on Fri, Jan 20, 2023 at 11:09:11 -0600:
> On 20 Jan 2023, Daniel Shahaf wrote:
> > Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00:
> > > I can complete the work on this branch and bring it to a
> > > production-ready
> > > state, assuming there are no objections.
> >
On 20.01.23 22:48, Karl Fogel wrote:
On 20 Jan 2023, Nathan Hartman wrote:
We already can't store files with identical SHA1 hashes, but AFAIK the
only meaningful impact we've ever heard is that security researchers
cannot track files they generate with deliberate collisions. The same
would be
On 20 Jan 2023, Nathan Hartman wrote:
Taking a step back, this discussion started because pristine-free
WCs
are IIUC more dependent on comparing hashes than pristineful WCs,
and
therefore a hash collision could have more impact in a
pristine-free
WC. "Guarantees" were mentioned, but I think it'
On 20 Jan 2023, Daniel Shahaf wrote:
Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00:
I can complete the work on this branch and bring it to a
production-ready
state, assuming there are no objections.
Your assumption is counterfactual:
https://mail-archives.apache.org/mod_mbox/s
Nathan Hartman wrote on Fri, 20 Jan 2023 14:51 +00:00:
> 1. Pros/cons of switching from SHA1 to another hash.
⋮
> Do we need to switch from SHA1 to another hash? One con that was
> already mentioned [1] is that we'll never really be able to switch
> away from SHA1, as there are
ble. I'm vetoing the change until a non-rubber-stamp design
> > discussion has been completed on the public dev@ list.
>
>
> I think we can start by discussing some of the pros and cons.
>
> There are two separate things here but they end up being mixed
> together in th
we can start by discussing some of the pros and cons.
There are two separate things here but they end up being mixed
together in the discussions:
1. Pros/cons of switching from SHA1 to another hash.
2. Supporting different hash types in f32.
Regarding the first item:
Do we need to switch from SH
Evgeny Kotkov via dev wrote on Thu, 19 Jan 2023 18:52 +00:00:
> I can complete the work on this branch and bring it to a production-ready
> state, assuming there are no objections.
Your assumption is counterfactual:
https://mail-archives.apache.org/mod_mbox/subversion-dev/202301.mbox/%3C202301191
store already contains an entry with the specified SHA-1
checksum. Switching
to a different checksum type for the pristine entries is going to
disable
that specific optimization. Re-enabling it would require an
update of the
server-side. I consider this to be out of scope for this branch.
I
On 19 Jan 2023, Daniel Shahaf wrote:
https://subversion.apache.org/security/sha1-advisory.txt
That's a well-written advisory. I was surprised to see that there
is no date on it, though -- from looking at the page, one would
have no quick way of knowing the date it was published (although
on
est if the pristine
store already contains an entry with the specified SHA-1 checksum. Switching
to a different checksum type for the pristine entries is going to disable
that specific optimization. Re-enabling it would require an update of the
server-side. I consider this to be out of scope for t
on
> > vacation for the New Year holidays.
>
> That's great to hear, Evgeny. In the meantime, enjoy your vacation!
Any news on this? Over here it's still not clear to me why what problem
would be solved by switching away from SHA-1, what alternative solutions
to that problem h
On 29 Dec 2022, Evgeny Kotkov wrote:
Karl Fogel writes:
Now, how hard would this be to actually implement?
I plan to take a more detailed look at that, but I'm currently on
vacation
for the New Year holidays.
That's great to hear, Evgeny. In the meantime, enjoy your
vacation!
Best re
witch to a new hash,
what is the problem we would like to solve with a new hash?
On the other hand, there can be no "switching to" a new hash, because
you don't know what the server actually supports -- hence, we'll always
have to keep SHA-1 around. :) IMO Karl described on
Karl Fogel writes:
> Now, how hard would this be to actually implement?
I plan to take a more detailed look at that, but I'm currently on vacation
for the New Year holidays.
Thanks,
Evgeny Kotkov
ount for a
lot more if I were volunteering to fix it, which I'm not alas.
But I do think we don't need to search further for justifications.
What we already know is enough: our hash algorithm is known to be
collidable, yet what we're using it for depends on
non-collidability; there
've been thinking about this question and while I don't know all
background, it seems to be two different questions:
- Detecting changes in the WC. Karl has an excellent scenario where this
might be a problem, but switching to a new hash only makes this scenario
more expensive. Thus: What
On 27.12.2022 02:56, Karl Fogel wrote:
Now, how hard would this be to actually implement? The
pristineless-format WC upgrade is an opportunity to make other format
changes, but I'd hate to block the release of pristineless working
copies on this...
My point was that we shouldn't have to worr
On 20 Dec 2022, Evgeny Kotkov via dev wrote:
[Moving discussion to a new thread]
We currently have a problem that a working copy relies on the
checksum type
with known collisions (SHA1). A solution to that problem is to
switch to a
different checksum type without known collisions in one of th
Evgeny Kotkov via dev wrote on Tue, Dec 20, 2022 at 11:14:00 +0300:
> [Moving discussion to a new thread]
>
> We currently have a problem that a working copy relies on the checksum type
> with known collisions (SHA1). A solution to that problem
Why is libsvn_wc's use of SHA-1 a problem? What's
On 20.12.2022 09:14, Evgeny Kotkov wrote:
2) We already need a working copy format bump for the pristines-on-demand
feature. So using that format bump to solve the SHA1 issue might reduce
the overall number of required bumps for users (assuming that we'll still
need to switch from SH
Karl Fogel writes:
> > While here, I would like to raise a topic of incorporating a switch from
> > SHA1 to a different checksum type (without known collisions) for the new
> > working copy format. This topic is relevant to the pristines-on-demand
> > branch, because the new "is the file modifie
-
From: Travis Brown [mailto:trav...@travisbrown.ca]
Sent: Saturday, August 24, 2013 5:58 PM
To: Les Mikesell; Ryan Schmidt; Branko ??ibej; Subversion;
dev@subversion.apache.org; John Maher
Subject: Re: Switching
On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug
On Sun, Aug 25, 2013 at 03:44:05PM -0700, Travis Brown wrote:
> I took a brief look at the resolution code and found it to be a twisty
> maze of callbacks and workqueues. There didn't appear to be any existing
> infrastructure or obvious way to resolve the tree conflict on the
> directory and then
On Sun, Aug 25, 2013 at 11:46:11AM +0200, Stefan Sperling claimed:
>Looking at just one use case is not going to help us in the long term.
>And I don't think we should hard-code conflict resolution behaviour in
>the update/switch/merge logic.
>
>During 1.8 development, I did experiment with hard-co
On Sat, Aug 24, 2013 at 02:57:50PM -0700, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
> >On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> >> That's just overcomplicating the issue. This doesn't even need to
> >> become a tree conflict.
> >
[not cross-posting to users@ as this is a dev@ topic]
On 24.08.2013 23:57, Travis Brown wrote:
> I'd be interested to hear of a single situation where _this_patch_,
> not some theoretical tree conflict resolving AI which bears no
> relation to this patch, does the wrong thing and the wrong thing i
On Sat, Aug 24, 2013 at 09:53:14PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
>> That's just overcomplicating the issue. This doesn't even need to
>> become a tree conflict.
>
>In my opinion it does need to be flagged as a conflict. Because we
>do
On 24.08.2013 21:26, Travis Brown wrote:
> On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>> On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>>> Don't forget that it was subversion, not the user, that created the
>>> directory and abandoned it in the first place.
>
On Sat, Aug 24, 2013 at 12:26:41PM -0700, Travis Brown wrote:
> That's just overcomplicating the issue. This doesn't even need to
> become a tree conflict.
In my opinion it does need to be flagged as a conflict. Because we
don't know what the contents of the incoming directory will be nor
what the
On Sat, Aug 24, 2013 at 09:04:48PM +0200, Stefan Sperling claimed:
>On Sat, Aug 24, 2013 at 10:22:41AM -0500, Les Mikesell wrote:
>> Don't forget that it was subversion, not the user, that created the
>> directory and abandoned it in the first place.
>
>If a previously versioned directory is left b
"C. Michael Pilato" writes:
> On 02/10/2011 04:58 AM, Philip Martin wrote:
>> I think this is fixed on trunk. I get your results with 1.6 and with
>> 1.7 I get:
>>
>> $ svnversion -c svn-wc.12027/
>> 2:5
>> $ svn st -v svn-wc.12027/
>> 65 pm svn-wc.12027
>>
On 02/10/2011 04:58 AM, Philip Martin wrote:
> I think this is fixed on trunk. I get your results with 1.6 and with
> 1.7 I get:
>
> $ svnversion -c svn-wc.12027/
> 2:5
> $ svn st -v svn-wc.12027/
> 65 pm svn-wc.12027
> 62 pm s
On Thu, Feb 10, 2011 at 10:58, Philip Martin wrote:
> Bert Wesarg writes:
>
>> svn switch ^/branches/branch
>> svn up
>> svn merge ^/trunk
>> svn ci -m "merging"
>> svn up
>> svnversion
>> # 6
>> svnversion -c
>> # 4:6
>> svn info
>> # Revision: 6
>> # Last Changed Rev: 6
>> svn switch ^/trunk
>>
Bert Wesarg writes:
> svn switch ^/branches/branch
> svn up
> svn merge ^/trunk
> svn ci -m "merging"
> svn up
> svnversion
> # 6
> svnversion -c
> # 4:6
> svn info
> # Revision: 6
> # Last Changed Rev: 6
> svn switch ^/trunk
> svn up
>
> # here it starts to show the wrong revision.
>
> svnversio
Hi,
I have svn version 1.6.12 (r955767) here.
Creating a new file in a subdirectory in ^/trunk, than merging this
^/trunk into a branch and switching back to ^/trunk, still shows me as
the last changed revision of this file in ^/trunk the merge revision
of the branch. The last changed revision
> -Original Message-
> From: neels [mailto:nee...@gmail.com]
> Sent: dinsdag 23 maart 2010 19:13
> To: Greg Stein
> Cc: Julian Foad; dev@subversion.apache.org
> Subject: Re: switching added files -- Re: What revision should an added
> not yet commited node have?
>
> "svn switch" talks about switching the repository location for nodes. The
> added (or copied/moved) nodes do not (yet) have a repository location, so
> they cannot be switched. They just follow the parent.
It's not like that is set in stone. An added node could have a
*p
uncommitted, added) nodes are *added* into the directory their
parent refers to. In the above example, you've switched the nodes which have
a correspondence in the repository, and the added nodes simply follow.
> this way, I prefer the analogy to a modified node, where the mods do
> stay
d from its parent during switch, OR we
should loudly fail, since we are not conforming to the requested
depth. Greg, are you saying we should bail on this case? Looking at it
this way, I prefer the analogy to a modified node, where the mods do
stay at the "unswitched" URL even if the parent
o we need to be able to support both in the WC? Yes, I believe so,
> and I would expect that as the "switch" mechanism handles the "specified
> repository path" concept, the normal mechanism should exclusively and
> comprehensively handle the "child of its WC pa
fied
repository path" concept, the normal mechanism should exclusively and
comprehensively handle the "child of its WC parent dir" concept.
Thoughts?
- Julian
On Mon, 2010-03-22, neels wrote:
> On 20 March 2010 06:02, Greg Stein wrote:
> > On Fri, Mar 19, 2010 a
On 20 March 2010 06:02, Greg Stein wrote:
> On Fri, Mar 19, 2010 at 12:37, neels wrote:
>> On 19 March 2010 07:37, Daniel Näslund wrote:
>>> I have some quirks with switching locally added files but that's for
>>> another post.
>>
>> I once teste
On Fri, Mar 19, 2010 at 12:37, neels wrote:
> On 19 March 2010 07:37, Daniel Näslund wrote:
>> I have some quirks with switching locally added files but that's for
>> another post.
>
> I once tested that switching the parent away depth-empty above an
> added node w
On 19 March 2010 07:37, Daniel Näslund wrote:
> I have some quirks with switching locally added files but that's for
> another post.
I once tested that switching the parent away depth-empty above an
added node works, and that the added node correctly keeps its previous
URL.
But I&#
80 matches
Mail list logo
