Re: Ignore every file except XX*

[Matt Simmons]

It would see the contents of the commit, though, and if the commit included
files not starting with XX, it could abort the commit, unless I'm
misunderstanding something here?

On Fri, Jun 12, 2020 at 5:00 AM Branko Čibej  wrote:

> On 12.06.2020 08:24, Matt Simmons wrote:
>
> Have you considered a pre-commit hook to deny anything not matching your
> rule?
>
>
> A pre-commit hook doesn't see the contents of the working copy, it's
> completely unsuitable for this use case.
>
> -- Brane
>
>
> On Thu, Jun 11, 2020 at 11:21 PM Branko Čibej  wrote:
>
>> On 12.06.2020 07:30, Daniel Sahlberg wrote:
>> > Hi,
>> >
>> > Thanks for your quick response!
>> >
>> >
>> > The way I solve a similar case is to set svn:ignore to '*', i.e.,
>> to
>> > ignore everything, then just 'svn add' the files I want under
>> version
>> > control. It's not ideal, as you'd miss the files you're interested
>> in.
>> >
>> >
>> > Already doing this. But sometimes we forget to 'svn add' a new file
>> > which then doesn't show up as modified. User error, surely, but if the
>> > mistake can be avoided :-)
>> >
>> >
>> > About feature design -- unfortunately we can't just invent a
>> > syntax that
>> > would invert the meaning of the glob patterns in svn:ignore, as
>> that
>> > would break backward compatibility. Any ideas for a solution would
>> be
>> > most welcome.
>> >
>> >
>> > Exactly my thoughts. The only solution I see is to add a new property
>> > svn:unignore which is applied after (or in conjunction with) the
>> > svn:ignore property. A file is ignored if it matches the svn:ignore
>> > glob pattern AND NOT matches the svn:unignore glob pattern. If
>> > svn:unignore is empty (or non-existent), the behaviour should be
>> > exactly the same as today.
>> >
>> > The code should be reasonably simple (but I have not analyzed if it
>> > would affect anything in the public interface) - only question if
>> > maintainers think a new property is a good idea.
>>
>> I can't think of a way to solve this without introducing a new property
>> (actually, two new properties, the other has to be the opposite of
>> svn:global-ignores). The code would, indeed, be quite simple; the
>> complex part has already been done, and adding the additional "and not
>> matches X" logic should be trivial.
>>
>> Care to move this over to dev@ with a patch?
>>
>> -- Brane
>>
> --
> "Today, vegetables... Tomorrow, the world!"
>
>
>

-- 
"Today, vegetables... Tomorrow, the world!"

Re: Ignore every file except XX*

[Matt Simmons]

Have you considered a pre-commit hook to deny anything not matching your
rule?

On Thu, Jun 11, 2020 at 11:21 PM Branko Čibej  wrote:

> On 12.06.2020 07:30, Daniel Sahlberg wrote:
> > Hi,
> >
> > Thanks for your quick response!
> >
> >
> > The way I solve a similar case is to set svn:ignore to '*', i.e., to
> > ignore everything, then just 'svn add' the files I want under version
> > control. It's not ideal, as you'd miss the files you're interested
> in.
> >
> >
> > Already doing this. But sometimes we forget to 'svn add' a new file
> > which then doesn't show up as modified. User error, surely, but if the
> > mistake can be avoided :-)
> >
> >
> > About feature design -- unfortunately we can't just invent a
> > syntax that
> > would invert the meaning of the glob patterns in svn:ignore, as that
> > would break backward compatibility. Any ideas for a solution would be
> > most welcome.
> >
> >
> > Exactly my thoughts. The only solution I see is to add a new property
> > svn:unignore which is applied after (or in conjunction with) the
> > svn:ignore property. A file is ignored if it matches the svn:ignore
> > glob pattern AND NOT matches the svn:unignore glob pattern. If
> > svn:unignore is empty (or non-existent), the behaviour should be
> > exactly the same as today.
> >
> > The code should be reasonably simple (but I have not analyzed if it
> > would affect anything in the public interface) - only question if
> > maintainers think a new property is a good idea.
>
> I can't think of a way to solve this without introducing a new property
> (actually, two new properties, the other has to be the opposite of
> svn:global-ignores). The code would, indeed, be quite simple; the
> complex part has already been done, and adding the additional "and not
> matches X" logic should be trivial.
>
> Care to move this over to dev@ with a patch?
>
> -- Brane
>
-- 
"Today, vegetables... Tomorrow, the world!"

Re: SHA-1 collision in repository?

[Matt Simmons]

I would get more advice from people here before you invest that time. I'm a
relative amateur and would listen to people with more experience than
myself.

--Matt

On Thu, Feb 22, 2018 at 2:29 PM, Myria <myriac...@gmail.com> wrote:

> That was one document we ran into when searching, yes.
>
> We can do an svnsync, but this will take about a week to run--the
> repository is 43 GB with 600,000 commits.  I guess we'll start it now.
>
> On Thu, Feb 22, 2018 at 2:04 PM, Matt Simmons <band...@gmail.com> wrote:
> > Hi Melissa,
> >
> > That definitely is interesting.
> >
> > I assume you have read
> > http://blogs.collab.net/subversion/subversion-sha1-
> collision-problem-statement-prevention-remediation-options
> >
> > If you do an svnsync to another location and attempt the commit there,
> does
> > the problem replicate itself?
> >
> > --Matt
> >
> >
> > On Thu, Feb 22, 2018 at 12:30 PM, Myria <myriac...@gmail.com> wrote:
> >>
> >> When we try to commit a very specific version of a very specific
> >> binary file, we get a SHA-1 collision error from the Subversion
> >> repository:
> >>
> >> D:\confidential>svn commit secret.bin -m "Testing broken commit"
> >> Sendingsecret.bin
> >> Transmitting file data .svn: E16: Commit failed (details follow):
> >> svn: E16: SHA1 of reps '604440 34 134255 136680
> >> c9f4fabc4d093612fece03c339401058
> >> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' and '-1 0
> >> 134255 136680 c9f4fabc4d093612fece03c339401058
> >> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' matches
> >> (db11617ef1454332336e00abc311d44bc698f3b3) but contents differ
> >>
> >>
> >> What can cause this?  This file is a binary pixel shader compiled from
> >> a build process.  It's most certainly not Google's SHA-1 collision PDF
> >> files.  We also scanned the repository to confirm that nobody has
> >> committed Google's collision files.
> >>
> >> Occam's Razor suggests that something is wrong with our repository or
> >> Subversion itself, rather than this being a true SHA-1 collision.  In
> >> that case, what is wrong with our repository?
> >>
> >> If this really is a SHA-1 collision, it would be major cryptography
> >> news that someone randomly ran into a second collision without even
> >> trying.  In that case, is there a method by which we could recover the
> >> two files that supposedly have the same SHA-1?  The collision doesn't
> >> appear to be in the file itself, but in some sort of diff or revision
> >> output?
> >>
> >> Thanks,
> >>
> >> Melissa
> >
> >
> >
> >
> > --
> > "Today, vegetables... Tomorrow, the world!"
>



-- 
"Today, vegetables... Tomorrow, the world!"

Re: SHA-1 collision in repository?

[Matt Simmons]

Hi Melissa,

That definitely is interesting.

I assume you have read
http://blogs.collab.net/subversion/subversion-sha1-collision-problem-statement-prevention-remediation-options


If you do an svnsync to another location and attempt the commit there, does
the problem replicate itself?

--Matt


On Thu, Feb 22, 2018 at 12:30 PM, Myria  wrote:

> When we try to commit a very specific version of a very specific
> binary file, we get a SHA-1 collision error from the Subversion
> repository:
>
> D:\confidential>svn commit secret.bin -m "Testing broken commit"
> Sendingsecret.bin
> Transmitting file data .svn: E16: Commit failed (details follow):
> svn: E16: SHA1 of reps '604440 34 134255 136680
> c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' and '-1 0
> 134255 136680 c9f4fabc4d093612fece03c339401058
> db11617ef1454332336e00abc311d44bc698f3b3 605556-czmh/_8' matches
> (db11617ef1454332336e00abc311d44bc698f3b3) but contents differ
>
>
> What can cause this?  This file is a binary pixel shader compiled from
> a build process.  It's most certainly not Google's SHA-1 collision PDF
> files.  We also scanned the repository to confirm that nobody has
> committed Google's collision files.
>
> Occam's Razor suggests that something is wrong with our repository or
> Subversion itself, rather than this being a true SHA-1 collision.  In
> that case, what is wrong with our repository?
>
> If this really is a SHA-1 collision, it would be major cryptography
> news that someone randomly ran into a second collision without even
> trying.  In that case, is there a method by which we could recover the
> two files that supposedly have the same SHA-1?  The collision doesn't
> appear to be in the file itself, but in some sort of diff or revision
> output?
>
> Thanks,
>
> Melissa
>



-- 
"Today, vegetables... Tomorrow, the world!"

Re: Hiding Subversion version number

[Matt Simmons]

OT, but you can see one here:

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-44ver2.pdf

(specifically, section 5.1: Reconfigure HTTP service banner (and others as
required) not to report Web server and OS type and version )

There are, of course, mandates to use up to date software, but, also many
other suggestions. Some practical, some just weird.

--Matt


On Sat, Dec 16, 2017 at 3:35 AM, Branko Čibej <br...@apache.org> wrote:

> On 15.12.2017 20:10, Matt Simmons wrote:
> > Many documents relating to information security compliance require
> > blocking visible software version information.
>
> Interesting documents. I'd have expected them to require all software to
> be patched to fix all known security bugs. I thought the "security by
> obscurity" mantra had been debunked, but apparently not ...
>
> -- Brane
>
> > On Fri, Dec 15, 2017 at 10:46 AM Nico Kadel-Garcia <nka...@gmail.com
> > <mailto:nka...@gmail.com>> wrote:
> >
> > Why would you want to hide this?
> >
> > On Fri, Dec 15, 2017 at 10:54 AM, Dave Huang <k...@azeotrope.org
> > <mailto:k...@azeotrope.org>> wrote:
> > > On Dec 15, 2017, at 9:15, Dhanushka Parakrama
> > <parakrama1...@gmail.com <mailto:parakrama1...@gmail.com>>
> > > wrote:
> > >
> > >
> > > Hi All
> > >
> > > Is there any configuration where i can hide  the subversion
> > version details
> > > .Please see copied image 
> >
> > --
> > "Today, vegetables... Tomorrow, the world!"
>
>


-- 
"Today, vegetables... Tomorrow, the world!"

Re: Hiding Subversion version number

[Matt Simmons]

This sounds like the ServerSignature directive

https://httpd.apache.org/docs/2.4/mod/core.html#serversignature

Have you turned it off?

On Fri, Dec 15, 2017 at 7:15 AM, Dhanushka Parakrama <
parakrama1...@gmail.com> wrote:

> Hi All
>
> Is there any configuration where i can hide  the subversion version
> details .Please see copied image [image: Inline images 1]
>



-- 
"Today, vegetables... Tomorrow, the world!"

Re: Hiding Subversion version number

[Matt Simmons]

Many documents relating to information security compliance require blocking
visible software version information.



On Fri, Dec 15, 2017 at 10:46 AM Nico Kadel-Garcia  wrote:

> Why would you want to hide this?
>
> On Fri, Dec 15, 2017 at 10:54 AM, Dave Huang  wrote:
> > On Dec 15, 2017, at 9:15, Dhanushka Parakrama 
> > wrote:
> >
> >
> > Hi All
> >
> > Is there any configuration where i can hide  the subversion version
> details
> > .Please see copied image 
>
-- 
"Today, vegetables... Tomorrow, the world!"

Re: Bug - svn hangs

[Matt Simmons]

What is /proc//fd/3 linked to?

On Sat, Dec 2, 2017 at 3:54 AM Luca Baraldi  wrote:

> Thanks Andreas.
>
> I just tried but my skills fall short on system calls.
>
> Seems it is blocked on the middle of a read() line, even the line seems
> half printed in the log...
>
> The line which would go as
>
> read(3, "( success ( ( ) 0: ) ) ( success"..., 16384) = 377
>
> In the bad case is
>
> read(3,
>
> And stayed there until I kill process...
>
> I can send you a goodTest and a badTest, outputted from strace. Both are
> "svn ls" of the same repository but different folders (good one is a parent
> folder of the bad one).
>
> Can you see something more?
>
> Thanks!
>
> Luca
>
>
>
> On 27/11/2017 10:16, Andreas Mohr wrote:
>
> On Sun, Nov 26, 2017 at 11:03:11PM +0100, Luca Baraldi wrote:
>
>I am blocked by this problem and cannot go on working with my pc.
>
> As an initial quick emergency hint by an outside person,
> try using strace/ltrace to figure out more context info
> (i.e., *why* it might be hanging).
>
> Good luck!
>
> Andreas Mohr
>
>
> --
> Luca *--Sent from my Pigeon Post*
>
-- 
"Today, vegetables... Tomorrow, the world!"

Re: Subversion svn+ssh, sshd 100% CPU

[Matt Simmons]

Why does iostat show? Could it be that your underlying disk is io-saturated
and your CPU spike is due to iowait?



On Tue, Sep 12, 2017 at 12:14 PM Zoran Petkovic 
wrote:

> In the past few days I have been doing extensive testing of Subversion
> with different clients, operating systems, client and server versions and
> have noticed very strange behaviour with windows clients connecting to
> Linux servers, hitting them with excessive CPU usage on the sshd process,
> where the Linux clients do not exhibit this behaviour.
>
>
>
> A sample test setup is as follows:
>
> Server Linux Ubuntu 16.04.3 LTS, OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL
> 1.0.2g  1 Mar 2016, Subversion version 1.9.3 (and 1.9.7).
>
> Client TortoiseSVN 1.9.7
>
>
>
> When checking out large repositories the linux server is hit on the sshd
> process, the process running with 100% cpu usage. This in effect slows down
> the performance and ultimately the speed at which the checkout runs. Linux
> clients connecting to the same server do not cause this load on the server.
>
>
>
> This happens even when compressions is turned off and when encryption
> Cyphers are changed, as well as different versions of subversion. The
> behaviour is identical. I'm not sure who to address for this issue as this
> not only happens with TortoiseSVN but with SlikSVN as well. Any direction
> would be appreciated.
>
>
>
> Regards,
>
>
>
> --
>
> Zoran Petkovic
>
>
>
-- 
"Today, vegetables... Tomorrow, the world!"