James McCoy writes:
> W: subversion/svn/commit-cmd.c:185,
> W: subversion/libsvn_client/commit.c:1096,
> W: subversion/libsvn_client/commit.c:156:
> (apr_err=SVN_ERR_STREAM_SEEK_NOT_SUPPORTED)
This error most likely happened due to an oversight in the pristine install
stream, and it should be a
Stefan Sperling writes:
> tagging Subversion 1.14.4
>
> Equivalent to 1.14.x@1920901 with the patch for CVE-2024-45720 applied.
>
> Added:
> subversion/tags/1.14.4/ (props changed)
> - copied from r1920901, subversion/branches/1.14.x/
> Modified:
> subversion/tags/1.14.4/CHANGES
>
Daniel Sahlberg writes:
> Log:
> On branch pristine-checksum-salt:
>
> Catchup merge with trunk
`pristine-checksum-salt` is branched off from branches/pristine-checksum-kind
(rather than from trunk), so in this case it should probably be better to
merge the trunk changes into the parent branch f
Daniel Sahlberg writes:
>> Index: subversion/libsvn_subr/io.c
>> ===
>> --- subversion/libsvn_subr/io.c (revision 1915064)
>> +++ subversion/libsvn_subr/io.c (working copy)
>> @@ -2535,7 +2535,14 @@ svn_io__is_finfo_read_only(svn_boo
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
Evgeny Kotkov writes:
> Merged in https://svn.apache.org/r1905955
>
> I'm going to respond on the topic of SHA1 a bit later.
For the history: thread [1] proposes the `pristine-checksum-salt` branch that
adds the infrastructure to support new pristine checksum kinds in the working
copy and makes
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.
Daniel Sahlberg writes:
> In the TortoiseSVN-dev group it is claimed to be because of APR 1.7.3 and
> that reverting back to 1.7.2 restores normal operation, I havn't yet
> verified nor tried to figure out which of the changes between 1.7.2
> and 1.7.3 may be responsible for this issue. As I know
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
Nathan Hartman writes:
> I think a good middle ground is:
>
> * Build with --enable-plaintext-password-storage by default; users who
> want to harden their system can do so, but will need to build their
> own client.
+1.
> * Set the default run-time config to store-plaintext-passwords = no
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
Jun Omae writes:
> After r1907965, build on Windows is failing with the following errors.
>
> [[[
> svn_client-1.lib(upgrade.obj) : error LNK2001: unresolved external symbol
> svn_wc__version_string_from_format
> [D:\a\subversion\subversion\build\win32\vcnet-vcproj\libsvn_client_dll.vcxproj]
>
Evgeny Kotkov writes:
> While working on the patch, I have stumbled across a couple of issues:
>
> A) `svn upgrade` without arguments fails for a working copy with latest format
>
> $ svn checkout --compatible-version=1.15 wc
> $ svn upgrade wc
> $ svn: E155021: Working copy '…' is already
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
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
Daniel Shahaf writes:
> > That could happen after a public disclosure of a pair of executable
> > files/scripts where the forged version allows for remote code execution.
> > Or maybe something similar with a file format that is often stored in
> > repositories and that can be executed or used by
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
Karl Fogel 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 passes all tes
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
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
Evgeny Kotkov writes:
> I think that the `pristines-on-demand-on-mwf` branch is now ready for a
> merge to trunk. I could do that, assuming there are no objections.
Merged in https://svn.apache.org/r1905955
I'm going to respond on the topic of SHA1 a bit later.
Thanks,
Evgeny Kotkov
Evgeny Kotkov writes:
> > IMHO, once the tests are ready, we could merge it and release
> > it to the world.
>
> Apart from the required test changes, there are some technical
> TODOs that remain from the initial patch and should be resolved.
> I'll try to handle them as well.
I think that the `
Bert Huijben writes:
> All the now deprecated functions now fail unconditionally when the setting
> is enabled. Isn’t it possible to do this more graceful whenever a file is
> encountered which misses it’s prisite version?
The problem with this approach is that the functions are going to work, b
Daniel Sahlberg writes:
>> + /** @since New in 1.15 */
>> + SVN_ERRDEF(SVN_ERR_WC_DEPRECATED_API_STORE_PRISTINE,
>> + SVN_ERR_WC_CATEGORY_START + 43,
>> + "This client was not updated to support working copies "
>> + "without local pristines")
>> +
>>/* f
Karl Fogel writes:
> Thank you, Evgeny! Just to make sure I understand correctly --
> the status now on the 'pristines-on-demand-on-mwf' branch is:
>
> 1) One can do 'svn checkout --store-pristines=no' to get an
> entirely pristine-less working copy. In that working copy,
> individual files wil
Evgeny Kotkov writes:
> Perhaps we could transition into that state by committing the patch
> and maybe re-evaluate things from there. I could do that, assuming
> no objections, of course.
Committed the patch in https://svn.apache.org/r1905324
I'll try to handle the related tasks in the near f
Karl Fogel writes:
> By the way, in that thread, Evgeny Kotkov -- whose initial work
> much of this is based on -- follows up with a patch that does a
> first-pass implementation of 'svn checkout --store-pristines=no'
> (by implementing a new persistent setting in wc.db).
Perhaps we could transi
27 matches
Mail list logo
