Re: PoshSvn – Subversion for PowerShell

[Justin MASSIOT | Zentek]

Awesome work Timofey, bravo and thanks for sharing!

Justin MASSIOT  |  Zentek


On Fri, 17 May 2024 at 09:55, Daniel Sahlberg 
wrote:

> Den fre 17 maj 2024 kl 06:45 skrev Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> On Thu, May 16, 2024 at 1:50 PM Timofey Zhakov  wrote:
>> >
>> > Hello everyone!
>> >
>> > I like Subversion and use it for my projects.
>> >
>> > PoshSvn is a PowerShell module which provides a tab competition and
>> > typed output for the Subversion cmdlets. I found it useful for
>> > scripting and everyday life.
>> >
>> > For example to get the status of a working copy, you could use the
>> > svn-status cmdlet:
>> >
>> > [[[
>> > PS C:\> svn-status
>> >
>> > Status  Path
>> > --  
>> > M   PoshSvn\CmdLets\SvnAdd.cs
>> > M   PoshSvn\CmdLets\SvnLog.cs
>> > M   PoshSvn\SvnCmdletBase.cs
>> > M   README.md
>> > ]]]
>> >
>> > This is useful for scripting because of typed output. For example:
>> >
>> > [[[
>> > PS C:\> $info = svn-info https://svn.apache.org/repos/asf
>> > PS C:\> $info.Revision
>> > 1917749
>> > PS C:\> $info.LastChangedAuthor
>> > projects_role
>> > ]]]
>> >
>> > Documentation is available at: https://www.poshsvn.com/
>> >
>> > The installation is very easy. Just type `Install-Module PoshSvn` in
>> > the PowerShell command prompt.
>> >
>> > This module is fully free and open source.
>> >
>> > Any kind of feedback would be much appreciated.
>> >
>> > Thanks!
>> >
>> > --
>> > Timofei Zhakov
>>
>>
>> Thanks for sharing!
>>
>> I'm not a Windows user or a PowerShell user so I can't try it out for
>> myself, but I am always glad to hear about new additions to the
>> Subversion ecosystem.
>>
>> If you ever feel like participating in Subversion development, there
>> are plenty of opportunities around here :-)
>>
>> Cheers,
>> Nathan
>>
>
> Dear Timofei,
>
> Very impressive work and I think this is the biggest addition to the
> Subversion ecosystem in may years.
>
> I'm a Windows user although I use PowerShell way to seldom. I will try to
> find time to test this out a little bit in the next few weeks.
>
> I was thinking about adding a link to your project on the Subversion
> website. There is already page for Binary packages[1] and this would make a
> nice addition. (Although, we have previously limited that page to strictly
> Apache Subversion builds and this a different kind of client, so we might
> have to create a new page for "ecosystem" - this should be discussed in the
> dev@ list).
>
> Kind regards,
> Daniel Sahlberg
>
> [1] https://subversion.apache.org/packages.html
>
>

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Daniel Sahlberg]

Den fre 17 maj 2024 kl 00:20 skrev Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users :

> > BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
> > that on the server or on the client?
>
> I've been testing with SVN 1.14.1 on both the client and server.
>

Perfect, thanks for confirming. Do you happen to know what version of Serf
is used on the client and what version of OpenSSL do you have on the
client/server?


>
> > Regardless, since the issue manifests on the client-side by hangs and
> > crashes while waiting for / processing data from the server (hangs
> > inside libsvn_ra_serf), I'd suggest also to investigate whether there
> > is something in between your client and your server that might be
> > interfering. A proxy or reverse proxy perhaps? Or some security
> > software on the client that interferes with the network (as some
> > antivirus suites do on Windows)? If so, try to bypass it (or disable /
> > create an exclude rule), as a diagnostic step to see whether this
> > might be the cause.
>
> I don't think we have anything inserted between client and server, but
> will ask those smarter than me if they know of such a thing.
>
> I do have an update.  My system administrator was surprised to see the
> server machine configured to support both version 4 and 6 IP addresses.  He
> thought the latter were turned off.  After that change, checkouts were
> noticeably faster, and hangs and crashes were noticeably less frequent.
> The repo size needed to trigger them appeared to grow some.  Though a step
> forward, the configuration still isn't useable.  It might also point at
> further network configuration problems as a cause, though the SVN client
> probably shouldn't crash in any case.
>

Are the client and the server both "close" (networkwise) or do they
communicate over a WAN/internet link?

Is it possible to - at least temporarily - add a VHost without SSL
encryption to see if this makes a difference? That would also make it
easier to catch the traffic using Wireshark to see the last packages before
a crash. In particular, I'm interested in the content of the packages that
trigger the xml parsing error (the call to svn_xml_parse). For the cases
when it hangs, does one side say "goodbye" (ie, FIN) or does it seem like
package drops (ie, traffic just stops flowing).

When it hangs, does it ever release? I would assume that the client would
finally time out.

Kind regards,
Daniel

Re: PoshSvn – Subversion for PowerShell

[Daniel Sahlberg]

Den fre 17 maj 2024 kl 06:45 skrev Nathan Hartman :

> On Thu, May 16, 2024 at 1:50 PM Timofey Zhakov  wrote:
> >
> > Hello everyone!
> >
> > I like Subversion and use it for my projects.
> >
> > PoshSvn is a PowerShell module which provides a tab competition and
> > typed output for the Subversion cmdlets. I found it useful for
> > scripting and everyday life.
> >
> > For example to get the status of a working copy, you could use the
> > svn-status cmdlet:
> >
> > [[[
> > PS C:\> svn-status
> >
> > Status  Path
> > --  
> > M   PoshSvn\CmdLets\SvnAdd.cs
> > M   PoshSvn\CmdLets\SvnLog.cs
> > M   PoshSvn\SvnCmdletBase.cs
> > M   README.md
> > ]]]
> >
> > This is useful for scripting because of typed output. For example:
> >
> > [[[
> > PS C:\> $info = svn-info https://svn.apache.org/repos/asf
> > PS C:\> $info.Revision
> > 1917749
> > PS C:\> $info.LastChangedAuthor
> > projects_role
> > ]]]
> >
> > Documentation is available at: https://www.poshsvn.com/
> >
> > The installation is very easy. Just type `Install-Module PoshSvn` in
> > the PowerShell command prompt.
> >
> > This module is fully free and open source.
> >
> > Any kind of feedback would be much appreciated.
> >
> > Thanks!
> >
> > --
> > Timofei Zhakov
>
>
> Thanks for sharing!
>
> I'm not a Windows user or a PowerShell user so I can't try it out for
> myself, but I am always glad to hear about new additions to the
> Subversion ecosystem.
>
> If you ever feel like participating in Subversion development, there
> are plenty of opportunities around here :-)
>
> Cheers,
> Nathan
>

Dear Timofei,

Very impressive work and I think this is the biggest addition to the
Subversion ecosystem in may years.

I'm a Windows user although I use PowerShell way to seldom. I will try to
find time to test this out a little bit in the next few weeks.

I was thinking about adding a link to your project on the Subversion
website. There is already page for Binary packages[1] and this would make a
nice addition. (Although, we have previously limited that page to strictly
Apache Subversion builds and this a different kind of client, so we might
have to create a new page for "ecosystem" - this should be discussed in the
dev@ list).

Kind regards,
Daniel Sahlberg

[1] https://subversion.apache.org/packages.html

Re: PoshSvn – Subversion for PowerShell

[Nathan Hartman]

On Thu, May 16, 2024 at 1:50 PM Timofey Zhakov  wrote:
>
> Hello everyone!
>
> I like Subversion and use it for my projects.
>
> PoshSvn is a PowerShell module which provides a tab competition and
> typed output for the Subversion cmdlets. I found it useful for
> scripting and everyday life.
>
> For example to get the status of a working copy, you could use the
> svn-status cmdlet:
>
> [[[
> PS C:\> svn-status
>
> Status  Path
> --  
> M   PoshSvn\CmdLets\SvnAdd.cs
> M   PoshSvn\CmdLets\SvnLog.cs
> M   PoshSvn\SvnCmdletBase.cs
> M   README.md
> ]]]
>
> This is useful for scripting because of typed output. For example:
>
> [[[
> PS C:\> $info = svn-info https://svn.apache.org/repos/asf
> PS C:\> $info.Revision
> 1917749
> PS C:\> $info.LastChangedAuthor
> projects_role
> ]]]
>
> Documentation is available at: https://www.poshsvn.com/
>
> The installation is very easy. Just type `Install-Module PoshSvn` in
> the PowerShell command prompt.
>
> This module is fully free and open source.
>
> Any kind of feedback would be much appreciated.
>
> Thanks!
>
> --
> Timofei Zhakov


Thanks for sharing!

I'm not a Windows user or a PowerShell user so I can't try it out for
myself, but I am always glad to hear about new additions to the
Subversion ecosystem.

If you ever feel like participating in Subversion development, there
are plenty of opportunities around here :-)

Cheers,
Nathan

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> > > > I've tried with multiple repos of different sizes and ages.  The
> > > smaller repo I mentioned has about 150 files in trunk, mostly 50 KB
> or
> > > smaller, and about 500 revisions.  A larger repo with the same
> problems
> > > has about 5000 files in trunk and 10,000 revisions.
> > >
> > > That *hints* at an httpd tuning issue, but I'm not sure. Check the
> httpd
> > > logs?
> >
> > The httpd logs show no signs of a problem.  Success and failure cases
> look the same in the logs.
> 
> In your initial post your mentioned:
> 
> >>> svn 1.10.2 was failing the same way before we upgraded to 1.14.1 as
> a possible fix.
> 
> So the problem isn't new after the upgrade.

Agreed.  I see no change in behavior, good or bad, between SVN 1.10.2 and 
1.14.1 for the many tests I've run.

> BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
> that on the server or on the client?

I've been testing with SVN 1.14.1 on both the client and server.

> Regardless, since the issue manifests on the client-side by hangs and
> crashes while waiting for / processing data from the server (hangs
> inside libsvn_ra_serf), I'd suggest also to investigate whether there
> is something in between your client and your server that might be
> interfering. A proxy or reverse proxy perhaps? Or some security
> software on the client that interferes with the network (as some
> antivirus suites do on Windows)? If so, try to bypass it (or disable /
> create an exclude rule), as a diagnostic step to see whether this
> might be the cause.

I don't think we have anything inserted between client and server, but will ask 
those smarter than me if they know of such a thing.

I do have an update.  My system administrator was surprised to see the server 
machine configured to support both version 4 and 6 IP addresses.  He thought 
the latter were turned off.  After that change, checkouts were noticeably 
faster, and hangs and crashes were noticeably less frequent.  The repo size 
needed to trigger them appeared to grow some.  Though a step forward, the 
configuration still isn't useable.  It might also point at further network 
configuration problems as a cause, though the SVN client probably shouldn't 
crash in any case.

Thanks for the reply.

Jim

PoshSvn – Subversion for PowerShell

[Timofey Zhakov]

Hello everyone!

I like Subversion and use it for my projects.

PoshSvn is a PowerShell module which provides a tab competition and
typed output for the Subversion cmdlets. I found it useful for
scripting and everyday life.

For example to get the status of a working copy, you could use the
svn-status cmdlet:

[[[
PS C:\> svn-status

Status  Path
--  
M   PoshSvn\CmdLets\SvnAdd.cs
M   PoshSvn\CmdLets\SvnLog.cs
M   PoshSvn\SvnCmdletBase.cs
M   README.md
]]]

This is useful for scripting because of typed output. For example:

[[[
PS C:\> $info = svn-info https://svn.apache.org/repos/asf
PS C:\> $info.Revision
1917749
PS C:\> $info.LastChangedAuthor
projects_role
]]]

Documentation is available at: https://www.poshsvn.com/

The installation is very easy. Just type `Install-Module PoshSvn` in
the PowerShell command prompt.

This module is fully free and open source.

Any kind of feedback would be much appreciated.

Thanks!

--
Timofei Zhakov

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Johan Corveleyn]

On Wed, May 15, 2024 at 12:41 AM Williams, James P. {Jim}
(JSC-CD4)[KBR Wyle Services, LLC] via users
 wrote:
> > From: Nico Kadel-Garcia 
> > Sent: Saturday, May 11, 2024 10:47 AM
...
> > > I've tried with multiple repos of different sizes and ages.  The
> > smaller repo I mentioned has about 150 files in trunk, mostly 50 KB or
> > smaller, and about 500 revisions.  A larger repo with the same problems
> > has about 5000 files in trunk and 10,000 revisions.
> >
> > That *hints* at an httpd tuning issue, but I'm not sure. Check the httpd
> > logs?
>
> The httpd logs show no signs of a problem.  Success and failure cases look 
> the same in the logs.

In your initial post your mentioned:

>>> svn 1.10.2 was failing the same way before we upgraded to 1.14.1 as a 
>>> possible fix.

So the problem isn't new after the upgrade.
BTW: as Daniel asked: You previously mentioned Subversion 1.14.1, is
that on the server or on the client?

Regardless, since the issue manifests on the client-side by hangs and
crashes while waiting for / processing data from the server (hangs
inside libsvn_ra_serf), I'd suggest also to investigate whether there
is something in between your client and your server that might be
interfering. A proxy or reverse proxy perhaps? Or some security
software on the client that interferes with the network (as some
antivirus suites do on Windows)? If so, try to bypass it (or disable /
create an exclude rule), as a diagnostic step to see whether this
might be the cause.

-- 
Johan

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> From: Nico Kadel-Garcia 
> Sent: Saturday, May 11, 2024 10:47 AM
> > > How did you upgrade your server from RHEL 6 to RHEL 8?
> >
> > Because so much changed from RHEL 6 to 8, including Apache from 2.2.15
> to 2.4.37, all the Apache modules, etc., I started from the skeleton
> configuration the operating system provides and made mostly the same
> customizations we had for RHEL 6, or modernized them where the docs said
> things changed.  Mostly, that was tweaks to authentication (from LDAP to
> Kerberos), SSL, and the SVN endpoints.  Browser access to all SVN and
> ViewVC pages seems to work fine.
> 
> Yeah. Forklift upgrades can be tricky. If I may suggest, segregate the
> httpd running Subversion from one doing *anything* else.

That was my plan too, to gradually strip off fluff and if necessary everything 
but SVN access to the repos.  I'll report back what I find.

> > I've tried with multiple repos of different sizes and ages.  The
> smaller repo I mentioned has about 150 files in trunk, mostly 50 KB or
> smaller, and about 500 revisions.  A larger repo with the same problems
> has about 5000 files in trunk and 10,000 revisions.
> 
> That *hints* at an httpd tuning issue, but I'm not sure. Check the httpd
> logs?

The httpd logs show no signs of a problem.  Success and failure cases look the 
same in the logs.

> > I thought svn:// worked only with svnserve, which we don't run.  Are
> you suggesting I try to run it as a test, or that I consider abandoning
> Apache in favor of it?  Yikes; that'd be painful.
> 
> I'm suggesting you at least run it as a test, to validate that your
> server's file systems and associated hardware are not messed up and
> hiding some deeper issue. Switch only if you need to. If that's too
> much work, you might try simply doing a file:/// based clone on the
> server itself..

Good ideas.  I'll try svnserve if my pared-down httpd configuration is 
inconclusive.  The same checkouts using file:// URLs are consistently 
successful.  That's not realistic for us, but it's still a useful data point, 
another indication the hangs are somehow in my server or network configuration. 
 The core dumps are still an SVN client problem, but may need whatever that 
wonkiness is to be tickled.

Jim

Re: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Daniel Sahlberg]

Hi,

I've added a few comments/questions below.

Kind regards,
Daniel Sahlberg

Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users :

> > How did you upgrade your server from RHEL 6 to RHEL 8?
>
> Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to
> 2.4.37, all the Apache modules, etc., I started from the skeleton
> configuration the operating system provides and made mostly the same
> customizations we had for RHEL 6, or modernized them where the docs said
> things changed.  Mostly, that was tweaks to authentication (from LDAP to
> Kerberos), SSL, and the SVN endpoints.  Browser access to all SVN and
> ViewVC pages seems to work fine.
>

You previously mentioned Subversion 1.14.1, is that on the server or on the
client?

[...]

> And do the problems happen if you use svn:// rather than https:// ?
>
> I thought svn:// worked only with svnserve, which we don't run.  Are you
> suggesting I try to run it as a test, or that I consider abandoning Apache
> in favor of it?  Yikes; that'd be painful.
>
> I hear you on the HTTP integration.  We have about 2000 repos and a few
> hundred developers.  I've supported that server for at least 15 years, and
> it hasn't been too bad...until now.
>

I have personally only ever used Subversion over http/https (except for
testing purposes) and I haven't had any of the problems described by Nico -
I guess YMMV...

Still it would be interesting to compare just to rule out a problem within
the repository. You can use svnserve directly or tunneled over SSH, see the
Subversion book:

https://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshauth



> On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
> Wyle Services, LLC] via users  wrote:
> >
> > I'm upgrading an Apache HTTP server of our SVN repos on RedHat
> Enterprise Linux 8.  Using Subversion 1.14.1, svn checkout of even a small,
> simple repo with about 150 files hangs about 90% of the time, crashes 5%,
> and succeeds 5%.  Given enough time, the hangs eventually time out after
> checking out much of the repo.  A debugger shows the following stack during
> the hang.
> >
> >
> >
> >   #0  epoll_wait   /usr/lib64/libc.so.6
>

Waiting for a reply from the server ... ?

Do you see any activity on the server (CPU / disk) during this time?


> >
> >   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
> >
> >   #2  serf_context_run /usr/lib64/libserf-1.so.0
> >
> >   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
> >
> >   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
> >
> >   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
> >
> >   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
> >
> >   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
> >
> >   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
> >
> >   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
> >
> >   #10 svn_cl.checkout
> >
> >   #11 sub_main
> >
> >   #12 main
> >
> >
> >
> > strace shows repeated calls to epoll_wait about 1 sec apart.
> >
> >
> >
> > When the checkout crashes, it's a SIGSEGV with this stack,
> >
> >
> >
> >   #0  apr_pool_create_ex(libapr-1.so.0)
>

Memory allocation?


> >
> >   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
> >
> >   #2  update_opened (libsvn_ra_serf-1.so.0)
> >
> >   #3  expat_start   (libsvn_ra_serf-1.so.0)
>

Parsing the XML message from the server?

Can you catch/view the actual XML message sent from the server? I'm
thinking if this is mangled in some strange way that is upsetting the XML
parser.


> >
> >   #4  expat_start_handler   (libsvn_subr-1.so.0)
> >
> >   #5  doContent (libexpat.so.1)
> >
> >   #6  contentProcessor  (libexpat.so.1)
> >
> >   #7  XML_ParseBuffer   (libexpat.so.1)
> >
> >   #8  svn_xml_parse (libsvn_subr-1.so.0)
> >
> >   #9  expat_response_handler(libsvn_ra_serf-1.so.0)
> >
> >   #10 process_buffer.isra.9 (libsvn_ra_serf-1.so.0)
> >
> >   #11 finish_report (libsvn_ra_serf-1.so.0)
> >
> >   #12 svn_wc_crawl_revisions5   (libsvn_wc-1.so.0)
> >
> >   #13 update_internal.isra.0(libsvn_client-1.so.0)
> >
> >   #14 svn_client__update_internal   (libsvn_client-1.so.0)
> >
> >   #15 svn_client__checkout_internal (libsvn_client-1.so.0)
> >
> >   #16 svn_client_checkout3  (libsvn_client-1.so.0)
> >
> >   #17 svn_cl__checkout  (svn)
> >
> >   #18 sub_main  (svn)
> >
> >   #19 main  (svn)
> >
> >   #20 __libc_start_main (libc.so.6)
> >
> >   #21 _start  

RE: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

> How did you upgrade your server from RHEL 6 to RHEL 8?

Because so much changed from RHEL 6 to 8, including Apache from 2.2.15 to 
2.4.37, all the Apache modules, etc., I started from the skeleton configuration 
the operating system provides and made mostly the same customizations we had 
for RHEL 6, or modernized them where the docs said things changed.  Mostly, 
that was tweaks to authentication (from LDAP to Kerberos), SSL, and the SVN 
endpoints.  Browser access to all SVN and ViewVC pages seems to work fine.

> Did you run "svnadmin upgrade" on the repo?

I haven't done anything to the repos.  SVN release notes between 1.10 and 1.14 
sounded like it was unnecessary, that a new server could operate on existing 
repos.  Regardless, I just ran "svnadmin upgrade" on these repos.  Some were 
bumped up to version 8, but it seems to have had no effect on the hangs and 
crashes.

> And just how *big* is the repo?

I've tried with multiple repos of different sizes and ages.  The smaller repo I 
mentioned has about 150 files in trunk, mostly 50 KB or smaller, and about 500 
revisions.  A larger repo with the same problems has about 5000 files in trunk 
and 10,000 revisions.

> Does your client setup work with a notably smaller repo?

Yeah, smaller repos are successful on most or all attempts.  The revision count 
seems to matter more than file count.  One with 150 files and 500 revisions 
fails almost every time.  One with 225 files but only 42 revisions succeeds 
almost every time.  All of the files are small, mostly 50 KB or smaller.

> And do the problems happen if you use svn:// rather than https:// ?

I thought svn:// worked only with svnserve, which we don't run.  Are you 
suggesting I try to run it as a test, or that I consider abandoning Apache in 
favor of it?  Yikes; that'd be painful.

I hear you on the HTTP integration.  We have about 2000 repos and a few hundred 
developers.  I've supported that server for at least 15 years, and it hasn't 
been too bad...until now.

Thanks for the reply.

Jim

-Original Message-
From: Nico Kadel-Garcia 
Sent: Friday, May 10, 2024 6:03 PM
To: Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] 

Cc: users@subversion.apache.org
Subject: [EXTERNAL] Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

CAUTION: This email originated from outside of NASA.  Please take care when 
clicking links or opening attachments.  Use the "Report Message" button to 
report suspicious messages to the NASA SOC.




How did you upgrade your server from RHEL 6 to RHEL 8? Did you run
"svnadmin upgrade" on the repo?  And just how *big* is the repo? Does
your client setup work with a notably smaller repo? And do the
problems happen if you use svn:// rather than https:// ? Because I've
been dealing with Subversion for a long time, and I have up on the
httpd integration years ago, The complex integration with an
overmuscled and constantly evolving, feature evolving webserver was
not something I bother with anymore, and it has big problems with big
repos, including its own repo over at http://svn.apache.org/repos/asf,
which can't be reliably synced anymore because it's gotten so large.

On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users  wrote:
>
> I'm upgrading an Apache HTTP server of our SVN repos on RedHat Enterprise 
> Linux 8.  Using Subversion 1.14.1, svn checkout of even a small, simple repo 
> with about 150 files hangs about 90% of the time, crashes 5%, and succeeds 
> 5%.  Given enough time, the hangs eventually time out after checking out much 
> of the repo.  A debugger shows the following stack during the hang.
>
>
>
>   #0  epoll_wait   /usr/lib64/libc.so.6
>
>   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
>
>   #2  serf_context_run /usr/lib64/libserf-1.so.0
>
>   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
>
>   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
>
>   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
>
>   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
>
>   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
>
>   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
>
>   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
>
>   #10 svn_cl.checkout
>
>   #11 sub_main
>
>   #12 main
>
>
>
> strace shows repeated calls to epoll_wait about 1 sec apart.
>
>
>
> When the checkout crashes, it's a SIGSEGV with this stack,
>
>
>
>   #0  apr_pool_create_ex(libapr-1.so.0)
>
>   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
>
>   #2  update_opened (libsvn_ra_serf-1.so.0)
>
>   #3  expat_start   (libsvn_ra_serf-1.so.0)
>
>   #4  expat_start_handler   (libsvn_subr-1.so.0)
>
>   #5  doContent (libexpat.so.1)
>
> 

Re: svn checkout Hangs/Crashes/Succeeds Over HTTP

[Nico Kadel-Garcia]

How did you upgrade your server from RHEL 6 to RHEL 8? Did you run
"svnadmin upgrade" on the repo?  And just how *big* is the repo? Does
your client setup work with a notably smaller repo? And do the
problems happen if you use svn:// rather than https:// ? Because I've
been dealing with Subversion for a long time, and I have up on the
httpd integration years ago, The complex integration with an
overmuscled and constantly evolving, feature evolving webserver was
not something I bother with anymore, and it has big problems with big
repos, including its own repo over at http://svn.apache.org/repos/asf,
which can't be reliably synced anymore because it's gotten so large.

On Fri, May 10, 2024 at 4:17 PM Williams, James P. {Jim} (JSC-CD4)[KBR
Wyle Services, LLC] via users  wrote:
>
> I'm upgrading an Apache HTTP server of our SVN repos on RedHat Enterprise 
> Linux 8.  Using Subversion 1.14.1, svn checkout of even a small, simple repo 
> with about 150 files hangs about 90% of the time, crashes 5%, and succeeds 
> 5%.  Given enough time, the hangs eventually time out after checking out much 
> of the repo.  A debugger shows the following stack during the hang.
>
>
>
>   #0  epoll_wait   /usr/lib64/libc.so.6
>
>   #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
>
>   #2  serf_context_run /usr/lib64/libserf-1.so.0
>
>   #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
>
>   #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
>
>   #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
>
>   #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
>
>   #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
>
>   #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
>
>   #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
>
>   #10 svn_cl.checkout
>
>   #11 sub_main
>
>   #12 main
>
>
>
> strace shows repeated calls to epoll_wait about 1 sec apart.
>
>
>
> When the checkout crashes, it's a SIGSEGV with this stack,
>
>
>
>   #0  apr_pool_create_ex(libapr-1.so.0)
>
>   #1  svn_pool_create_ex(libsvn_subr-1.so.0)
>
>   #2  update_opened (libsvn_ra_serf-1.so.0)
>
>   #3  expat_start   (libsvn_ra_serf-1.so.0)
>
>   #4  expat_start_handler   (libsvn_subr-1.so.0)
>
>   #5  doContent (libexpat.so.1)
>
>   #6  contentProcessor  (libexpat.so.1)
>
>   #7  XML_ParseBuffer   (libexpat.so.1)
>
>   #8  svn_xml_parse (libsvn_subr-1.so.0)
>
>  #9  expat_response_handler(libsvn_ra_serf-1.so.0)
>
>   #10 process_buffer.isra.9 (libsvn_ra_serf-1.so.0)
>
>   #11 finish_report (libsvn_ra_serf-1.so.0)
>
>   #12 svn_wc_crawl_revisions5   (libsvn_wc-1.so.0)
>
>   #13 update_internal.isra.0(libsvn_client-1.so.0)
>
>   #14 svn_client__update_internal   (libsvn_client-1.so.0)
>
>   #15 svn_client__checkout_internal (libsvn_client-1.so.0)
>
>   #16 svn_client_checkout3  (libsvn_client-1.so.0)
>
>   #17 svn_cl__checkout  (svn)
>
>   #18 sub_main  (svn)
>
>   #19 main  (svn)
>
>   #20 __libc_start_main (libc.so.6)
>
>   #21 _start(svn)
>
>
>
> or this one,
>
>
>
>   #0  apr_allocator_alloc  (libapr-1.so.0)
>
>   #1  serf_bucket_mem_alloc(libserf-1.so.0)
>
>   #2  serf_bucket_response_create  (libserf-1.so.0)
>
>   #3  serf.process_connection  (libserf-1.so.0)
>
>   #4  serf_event_trigger   (libserf-1.so.0)
>
>   #5  serf_context_run (libserf-1.so.0)
>
>   #6  svn_ra_serf.context_run  (libsvn_ra_serf-1.so.0)
>
>   #7  finish_report(libsvn_ra_serf-1.so.0)
>
>   #8  svn_wc_crawl_revisions5  (libsvn_wc-1.so.0)
>
>   #9  update_internal.isra (libsvn_client-1.so.0)
>
>   #10 svn_client.update_internal   (libsvn_client-1.so.0)
>
>   #11 svn_client.checkout_internal (libsvn_client-1.so.0)
>
>   #12 svn_client_checkout3 (libsvn_client-1.so.0)
>
>   #13 svn_cl.checkout  (svn)
>
>   #14 sub_main (svn)
>
>   #15 main (svn)
>
>
>
> After a failure, I'm left with a half-checked out working copy with many 
> locks.  I can complete it with svn cleanup and another svn checkout, but 
> that's not realistic for our CI/CD or general use.  Server logs show no 
> indication of a problem; the server appears healthy.
>
>
>
> I've tried a million things before submitting this bug report, read half a 
> million posts and searches, but haven't been able to get past this.  I'd sure 
> appreciate any ideas you have on the way forward.  Here's a bit more about my 

svn checkout Hangs/Crashes/Succeeds Over HTTP

[Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users]

I'm upgrading an Apache HTTP server of our SVN repos on RedHat Enterprise Linux 
8.  Using Subversion 1.14.1, svn checkout of even a small, simple repo with 
about 150 files hangs about 90% of the time, crashes 5%, and succeeds 5%.  
Given enough time, the hangs eventually time out after checking out much of the 
repo.  A debugger shows the following stack during the hang.

  #0  epoll_wait   /usr/lib64/libc.so.6
  #1  impl_pollset_poll/usr/lib64/libapr-1.so.0
  #2  serf_context_run /usr/lib64/libserf-1.so.0
  #3  svn_ra_serf.context_run  /usr/lib64/libsvn_ra_serf-1.so.0
  #4  finish_report/usr/lib64/libsvn_ra_serf-1.so.0
  #5  svn_wc_crawl_revisions5  /usr/lib64/libsvn_wc-1.so.0
  #6  update_internal.isra /usr/lib64/libsvn_client-1.so.0
  #7  svn_client.update_internal   /usr/lib64/libsvn_client-1.so.0
  #8  svn_client.checkout_internal /usr/lib64/libsvn_client-1.so.0
  #9  svn_client_checkout3 /usr/lib64/libsvn_client-1.so.0
  #10 svn_cl.checkout
  #11 sub_main
  #12 main

strace shows repeated calls to epoll_wait about 1 sec apart.

When the checkout crashes, it's a SIGSEGV with this stack,

  #0  apr_pool_create_ex(libapr-1.so.0)
  #1  svn_pool_create_ex(libsvn_subr-1.so.0)
  #2  update_opened (libsvn_ra_serf-1.so.0)
  #3  expat_start   (libsvn_ra_serf-1.so.0)
  #4  expat_start_handler   (libsvn_subr-1.so.0)
  #5  doContent (libexpat.so.1)
  #6  contentProcessor  (libexpat.so.1)
  #7  XML_ParseBuffer   (libexpat.so.1)
  #8  svn_xml_parse (libsvn_subr-1.so.0)
 #9  expat_response_handler(libsvn_ra_serf-1.so.0)
  #10 process_buffer.isra.9 (libsvn_ra_serf-1.so.0)
  #11 finish_report (libsvn_ra_serf-1.so.0)
  #12 svn_wc_crawl_revisions5   (libsvn_wc-1.so.0)
  #13 update_internal.isra.0(libsvn_client-1.so.0)
  #14 svn_client__update_internal   (libsvn_client-1.so.0)
  #15 svn_client__checkout_internal (libsvn_client-1.so.0)
  #16 svn_client_checkout3  (libsvn_client-1.so.0)
  #17 svn_cl__checkout  (svn)
  #18 sub_main  (svn)
  #19 main  (svn)
  #20 __libc_start_main (libc.so.6)
  #21 _start(svn)

or this one,

  #0  apr_allocator_alloc  (libapr-1.so.0)
  #1  serf_bucket_mem_alloc(libserf-1.so.0)
  #2  serf_bucket_response_create  (libserf-1.so.0)
  #3  serf.process_connection  (libserf-1.so.0)
  #4  serf_event_trigger   (libserf-1.so.0)
  #5  serf_context_run (libserf-1.so.0)
  #6  svn_ra_serf.context_run  (libsvn_ra_serf-1.so.0)
  #7  finish_report(libsvn_ra_serf-1.so.0)
  #8  svn_wc_crawl_revisions5  (libsvn_wc-1.so.0)
  #9  update_internal.isra (libsvn_client-1.so.0)
  #10 svn_client.update_internal   (libsvn_client-1.so.0)
  #11 svn_client.checkout_internal (libsvn_client-1.so.0)
  #12 svn_client_checkout3 (libsvn_client-1.so.0)
  #13 svn_cl.checkout  (svn)
  #14 sub_main (svn)
  #15 main (svn)

After a failure, I'm left with a half-checked out working copy with many locks. 
 I can complete it with svn cleanup and another svn checkout, but that's not 
realistic for our CI/CD or general use.  Server logs show no indication of a 
problem; the server appears healthy.

I've tried a million things before submitting this bug report, read half a 
million posts and searches, but haven't been able to get past this.  I'd sure 
appreciate any ideas you have on the way forward.  Here's a bit more about my 
system.


  *   svn, version 1.14.1 (r1886195)
 * ra_svn : Module for accessing a repository using the svn network 
protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
 * ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
 * ra_serf : Module for accessing a repository via WebDAV protocol using 
serf.
  - using serf 1.3.9 (compiled with 1.3.9)
  - handles 'http' scheme
  - handles 'https' scheme

 The following authentication credential caches are available:

 * Plaintext cache in /home/me/.subversion
 * Gnome Keyring
 * GPG-Agent

  *   svn 1.10.2 was failing the same way before we upgraded to 1.14.1 as a 
possible fix.
  *   Checking out to a local disk succeeds more often, but still hangs and 
crashes.  Checking out to an NFS drive just makes it worse.

And here's more about our Apache.


  *   Server version: Apache/2.4.37 (Red Hat Enterprise Linux)

Server built:   Aug 30 2023 11:01:53

Server's Module Magic Number: 20120211:83

svn-books.com

[Tuukka Tuominen]

Hi!

You seem to be the owner of the domain name svnbook.com, so I thought you
might be interested in svn-books.com? If so, please let me know and I will
send you more information.

Have a great day!
Tuukka Tuominen

Re: TortoiseSVN & Office 365 Single Sign-On

[Pavel Lyalyakin via users]

On Tue, 30 Apr 2024 at 10:54, Daniel Sahlberg
 wrote:
>
>
> Den tis 30 apr. 2024 kl 05:37 skrev Jason Vietri 
> :
>>
>> Hi everyone,
>>
>> Is there a way to configure Office 365 Single Sign-On within TortoiseSVN so 
>> our users can be authenticated using their Office 365 credentials? I 
>> appreciate your help.
>>
>> Thank you all for your time and effort. I hope you have a wonderful day!
>>
>>
>>
>> Jason Vietri
>
>
>
> Hi,
>
> I saw you also posted on the TortoiseSVN forums 
> (https://groups.google.com/g/tortoisesvn/c/bfBdlKdSzbw). As I replied there, 
> this was discussed a while back 
> (https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8) and also on the 
> Subversion dev list 
> (https://lists.apache.org/thread/f3f516vkm16ss67g9xfrjrfdcp70ymd0).

Subversion supports Kerberos. And Entra Kerberos (Azure Kerberos)
should let you authenticate in Hybrid Entra ID environments using your
Entra ID credentials (and AFAIK Office 365 is Entra ID / Azure AD).
Windows can now request a Kerberos Granting Ticket from a cloud
Kerberos KDC and use it to access file shares and AD services that
natively support Kerberos. But now this requires a hybrid-joined
Windows device.

Check my earlier email:
https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8/m/P1-0m8_sAAAJ

--
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: TortoiseSVN & Office 365 Single Sign-On

[EML]

On 30/04/2024 08:49, Daniel Sahlberg wrote:


I saw you also posted on the TortoiseSVN forums 
(https://groups.google.com/g/tortoisesvn/c/bfBdlKdSzbw). As I replied 
there, this was discussed a while back 
(https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8) and also 
on the Subversion dev list 
(https://lists.apache.org/thread/f3f516vkm16ss67g9xfrjrfdcp70ymd0).


I'm very interested in getting this working but unfortunately I don't 
have much time to do it myself right now.


I'm still here; just clearing some other stuff off the decks right now, 
but I was hoping to start looking at this in about a month. Meanwhile, 
could someone let me know what the connection between TSVN and the plain 
svn client actually is? Would the code have to be written twice, or 
would it be sufficient just to put it in svn?


And maybe someone could set me up to get a checkout?

-Evan



Kind regards,
Daniel Sahlberg


IT & Security Manager

514-578-7864

450-441-6464 x413

jason.vie...@certcentercanada.com

Book time with Jason Vietri

-
https://bit.ly/vietri

signatureImage

*Cert Center Canada *

50 Chemin de la Rabastalière est, suite 23A

Saint-Bruno-de-Montarville QC  J3V 2A5

Canada

Re: TortoiseSVN & Office 365 Single Sign-On

[Daniel Sahlberg]

Den tis 30 apr. 2024 kl 05:37 skrev Jason Vietri <
jason.vie...@certcentercanada.com>:

> Hi everyone,
>
> Is there a way to configure Office 365 Single Sign-On within TortoiseSVN
> so our users can be authenticated using their Office 365 credentials? I
> appreciate your help.
>
> Thank you all for your time and effort. I hope you have a wonderful day!
>
>
>
> Jason Vietri
>


Hi,

I saw you also posted on the TortoiseSVN forums (
https://groups.google.com/g/tortoisesvn/c/bfBdlKdSzbw). As I replied there,
this was discussed a while back (
https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8) and also on the
Subversion dev list (
https://lists.apache.org/thread/f3f516vkm16ss67g9xfrjrfdcp70ymd0).

I'm very interested in getting this working but unfortunately I don't have
much time to do it myself right now.

Kind regards,
Daniel Sahlberg




> IT & Security Manager
>
> 514-578-7864
>
> 450-441-6464 x413
>
> jason.vie...@certcentercanada.com
>
> Book time with Jason Vietri
> -
> https://bit.ly/vietri
>
> [image: signatureImage]
>
>
>
> *Cert Center Canada *
>
> 50 Chemin de la Rabastalière est, suite 23A
>
> Saint-Bruno-de-Montarville  QC  J3V 2A5
>
> Canada
>
>
>

TortoiseSVN & Office 365 Single Sign-On

[Jason Vietri]

Hi everyone,

Is there a way to configure Office 365 Single Sign-On within TortoiseSVN so our 
users can be authenticated using their Office 365 credentials? I appreciate 
your help.


Thank you all for your time and effort. I hope you have a wonderful day!



Jason Vietri

IT & Security Manager

514-578-7864

450-441-6464 x413

jason.vie...@certcentercanada.com

Book time with Jason Vietri 

 - https://bit.ly/vietri

[signatureImage]



Cert Center Canada

50 Chemin de la Rabastalière est, suite 23A

Saint-Bruno-de-Montarville  QC  J3V 2A5

Canada

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[Doug Robinson]

On Fri, Apr 19, 2024 at 3:32 PM BK  wrote:

> If the parser behaves like this in version 1.14, I take it as a given.
> I would be interested to know the reasons for this change?
>
The parsing change was actually made in 1.10.  It was done in order to
implement "wildcarding" in path-based AuthZ [0].
Background [1], additional information [2].

tl;dr: With the implementation of wildcarding the ordering of the sections
in the AuthZ file have become critical.

Also note: as of SVN 1.10 the parsing of the AuthZ file now takes longer.
Small AuthZ files won't likely see the issue but large AuthZ files can
cause user-visible delays from Apache/svnserve.  The workaround I've been
using is to break up the single "super" AuthZ files into per-repository
AuthZ files and use the Apache "AuthzSVNReposRelativeAccessFile" directive
(see example 4 in [3]).

> From the per repository point of view it didn't really help the clarity.
> But maybe there are more important reasons for the change.
>
I hope the above helps.

Cheers.

Doug
--
[0] https://subversion.apache.org/docs/release-notes/1.10.html#authzperf
[1] https://cwiki.apache.org/confluence/display/SVN/Authz+Improvements
[2] https://svn.haxx.se/dev/archive-2017-02/att-0188/
[3]
https://svn.apache.org/repos/asf/subversion/branches/1.10.x/subversion/mod_authz_svn/INSTALL


> Unfortunately, I don't have the expertise
> or sufficient programming knowledge to submit a patch.
>
> Best Regards,
> Bernhard
>
>
> Am 18.04.24 um 10:28 schrieb Daniel Sahlberg:
>
> The code as it is now seems to be very intentionally written to NOT allow
> multiple sections with the same name, see the check_open_section() function
> in authz_parse.c[1].
>
> I don't know if it would be possible to relax this restriction but feel
> free to take a look at the code and send a patch to
> d...@subversion.apache.org.
>
> It is not possible to switch back to the old authz parse code in version
> 1.14.
>
> Kind regards,
> Daniel
>
>

-- 
*Doug Robinson*  Senior Product Manager
P +1 925 396 1125
*E* doug.robin...@cirata.com

-- 





THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY AND MAY 
BE PRIVILEGED


If this message was misdirected, Cirata Ltd. and its 
subsidiaries, ("Cirata") does not waive any confidentiality or privilege. 
If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone. Any 
distribution, use or copying of this email or the information it contains 
by other than an intended recipient is unauthorized. The views and opinions 
expressed in this email message are the author's own and may not reflect 
the views and opinions of Cirata, unless the author is authorized by Cirata 
to express such views or opinions on its behalf. All email sent to or from 
this address is subject to electronic storage and review by Cirata. 
Although Cirata operates anti-virus programs, it does not accept 
responsibility for any damage whatsoever caused by viruses being passed.

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[BK]

If the parser behaves like this in version 1.14, I take it as a given.
I would be interested to know the reasons for this change?
From the per repository point of view it didn't really help the clarity.
But maybe there are more important reasons for the change.
Unfortunately, I don't have the expertise
or sufficient programming knowledge to submit a patch.

Best Regards,
Bernhard


Am 18.04.24 um 10:28 schrieb Daniel Sahlberg:

The code as it is now seems to be very intentionally written to NOT
allow multiple sections with the same name, see the
check_open_section() function in authz_parse.c[1].

I don't know if it would be possible to relax this restriction but
feel free to take a look at the code and send a patch to
d...@subversion.apache.org.

It is not possible to switch back to the old authz parse code in
version 1.14.

Kind regards,
Daniel

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[Daniel Sahlberg]

Den ons 17 apr. 2024 kl 15:32 skrev BK :

> Hello Pavel,
>
> That is the question.
> Is it possible in version 1.14 to keep this format
> (per repository) as it is possible in version 1.8?
> I think this is clearer with a large number
> of repositories on the server.
>
The code as it is now seems to be very intentionally written to NOT allow
multiple sections with the same name, see the check_open_section() function
in authz_parse.c[1].

I don't know if it would be possible to relax this restriction but feel
free to take a look at the code and send a patch to
d...@subversion.apache.org.

It is not possible to switch back to the old authz parse code in version
1.14.

Kind regards,
Daniel



[1]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_repos/authz_parse.c?revision=1875971=markup#l310



> Regards,
> Bernhard
>
>
> Am 17.04.24 um 14:16 schrieb Pavel Lyalyakin:
>
> On Wed, 17 Apr 2024 at 15:08, BK   wrote:
>
> Hello,
>
> After the change from Subversion 1.8 to 1.14 on my server
> the access rights definitions in the svn_access_file
> no longer work.
> The following error message appears:
> [authz_svn:error] Failed to load the mod_authz_svn config: Error while 
> parsing config file: '/opt/csvn/release/data/conf/svn_access_file': svnauthz: 
> E220003: Section appears more than once in the authz file: [groups]
>
> Is it no longer possible to define groups more than once
> per repository in the acccess file? I find this style
> more clearly organised, than to separate all groups
> of the repos and the corresponding access rights
> separate.
>
> Is there a possibility to stay in the old format (Subvesion 1.8)?
>
> Here is an extract from the svn_access_file file.
>
> ##
> # server administrators
> ##
> [groups]
> ApplicationServerAdmins = svnadm, admim1
>
> # ---
> # access rules for entire server content
> # ---
> [/]
> @ApplicationServerAdmins = rw
>
>
> ##
> # test1
> ##
> [groups]
> test1_Administration = @ApplicationServerAdmins, user1
> test1_Users = user1
>
> # ---
> # access rules
> # ---
> [test1:/]
> @test1_Administration = rw
> [test1:/tags/to1/t1]
> @test1_Users = rw
>
>
> ##
> # jira_test
> ##
> [groups]
> jira_test_Administration = @ApplicationServerAdmins, admin2
> jira_test_Developer = user2
>
> # ---
> # access rules
> # ---
> [jira_test:/]
> @jira_test_Administration = rw
> @jira_test_Developer = rw
>
>
> Thanks for your help,
> Bernard
>
> I'm not familiar with this particular issue and the error message. But
> why does your authz file have multiple [groups] sections? I think that
> you should clean up the file and 1) Remove unnecessary entries. 2)
> Group all group definitions in a single [groups] section.
>
>
>

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[BK]

Hello Pavel,

That is the question.
Is it possible in version 1.14 to keep this format
(per repository) as it is possible in version 1.8?
I think this is clearer with a large number
of repositories on the server.

Regards,
Bernhard


Am 17.04.24 um 14:16 schrieb Pavel Lyalyakin:

On Wed, 17 Apr 2024 at 15:08, BK  wrote:

Hello,

After the change from Subversion 1.8 to 1.14 on my server
the access rights definitions in the svn_access_file
no longer work.
The following error message appears:
[authz_svn:error] Failed to load the mod_authz_svn config: Error while parsing 
config file: '/opt/csvn/release/data/conf/svn_access_file': svnauthz: E220003: 
Section appears more than once in the authz file: [groups]

Is it no longer possible to define groups more than once
per repository in the acccess file? I find this style
more clearly organised, than to separate all groups
of the repos and the corresponding access rights
separate.

Is there a possibility to stay in the old format (Subvesion 1.8)?

Here is an extract from the svn_access_file file.

##
# server administrators
##
[groups]
ApplicationServerAdmins = svnadm, admim1

# ---
# access rules for entire server content
# ---
[/]
@ApplicationServerAdmins = rw


##
# test1
##
[groups]
test1_Administration = @ApplicationServerAdmins, user1
test1_Users = user1

# ---
# access rules
# ---
[test1:/]
@test1_Administration = rw
[test1:/tags/to1/t1]
@test1_Users = rw


##
# jira_test
##
[groups]
jira_test_Administration = @ApplicationServerAdmins, admin2
jira_test_Developer = user2

# ---
# access rules
# ---
[jira_test:/]
@jira_test_Administration = rw
@jira_test_Developer = rw


Thanks for your help,
Bernard

I'm not familiar with this particular issue and the error message. But
why does your authz file have multiple [groups] sections? I think that
you should clean up the file and 1) Remove unnecessary entries. 2)
Group all group definitions in a single [groups] section.

Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[BK]

Hello,

After the change from Subversion 1.8 to 1.14 on my server
the access rights definitions in the svn_access_file
no longer work.
The following error message appears:
[authz_svn:error] Failed to load the mod_authz_svn config: Error while
parsing config file: '/opt/csvn/release/data/conf/svn_access_file':
svnauthz: E220003: Section appears more than once in the authz file:
[groups]

Is it no longer possible to define groups more than once
per repository in the acccess file? I find this style
more clearly organised, than to separate all groups
of the repos and the corresponding access rights
separate.

Is there a possibility to stay in the old format (Subvesion 1.8)?

Here is an extract from the svn_access_file file.

##
# server administrators
##
[groups]
ApplicationServerAdmins = svnadm, admim1

# ---
# access rules for entire server content
# ---
[/]
@ApplicationServerAdmins = rw


##
# test1
##
[groups]
test1_Administration = @ApplicationServerAdmins, user1
test1_Users = user1

# ---
# access rules
# ---
[test1:/]
@test1_Administration = rw
[test1:/tags/to1/t1]
@test1_Users = rw


##
# jira_test
##
[groups]
jira_test_Administration = @ApplicationServerAdmins, admin2
jira_test_Developer = user2

# ---
# access rules
# ---
[jira_test:/]
@jira_test_Administration = rw
@jira_test_Developer = rw


Thanks for your help,
Bernard

Re: Error | svnauthz: E220003: Section appears more than once in the authz file: [groups]

[Pavel Lyalyakin via users]

On Wed, 17 Apr 2024 at 15:08, BK  wrote:
>
> Hello,
>
> After the change from Subversion 1.8 to 1.14 on my server
> the access rights definitions in the svn_access_file
> no longer work.
> The following error message appears:
> [authz_svn:error] Failed to load the mod_authz_svn config: Error while 
> parsing config file: '/opt/csvn/release/data/conf/svn_access_file': svnauthz: 
> E220003: Section appears more than once in the authz file: [groups]
>
> Is it no longer possible to define groups more than once
> per repository in the acccess file? I find this style
> more clearly organised, than to separate all groups
> of the repos and the corresponding access rights
> separate.
>
> Is there a possibility to stay in the old format (Subvesion 1.8)?
>
> Here is an extract from the svn_access_file file.
>
> ##
> # server administrators
> ##
> [groups]
> ApplicationServerAdmins = svnadm, admim1
>
> # ---
> # access rules for entire server content
> # ---
> [/]
> @ApplicationServerAdmins = rw
>
>
> ##
> # test1
> ##
> [groups]
> test1_Administration = @ApplicationServerAdmins, user1
> test1_Users = user1
>
> # ---
> # access rules
> # ---
> [test1:/]
> @test1_Administration = rw
> [test1:/tags/to1/t1]
> @test1_Users = rw
>
>
> ##
> # jira_test
> ##
> [groups]
> jira_test_Administration = @ApplicationServerAdmins, admin2
> jira_test_Developer = user2
>
> # ---
> # access rules
> # ---
> [jira_test:/]
> @jira_test_Administration = rw
> @jira_test_Developer = rw
>
>
> Thanks for your help,
> Bernard

I'm not familiar with this particular issue and the error message. But
why does your authz file have multiple [groups] sections? I think that
you should clean up the file and 1) Remove unnecessary entries. 2)
Group all group definitions in a single [groups] section.

-- 
With best regards,
Pavel Lyalyakin
VisualSVN Team

Re: Feature request: distinguish between disconnect to server and to proxy

[Daniel Sahlberg]

Den tors 11 apr. 2024 kl 19:17 skrev Mikhail Dvorkin <
mikhail.dvor...@gmail.com>:

> I received this error when doing 'svn update':
>
> svn: E170013: Unable to connect to a repository at URL …
>
> I spent many minutes trying to find why the perfectly working server
> would not grant a connection.
>
> The solution was: for years in my TortoiseSVN settings a proxy server
> was selected, and it simply has been working until it happened to be
> turned off.
>
> So I ask for one of two features:
>
> A) When "unable to connect to a server", make an extra check whether
> it is possible to connect to the proxy server (if one is selected). If
> this is the case, make the error more verbose, like:
>
> svn: E170013: Unable to connect to a repository at URL …, also unable
> to connect to a proxy …
>
> B) Simply make the error message more verbose if the proxy server is
> selected in the settings, like:
>
> svn: E170013: Unable to connect to a repository at URL …
> (Note: proxy … was used for connection)
>

Hi,

While I think the idea in principle sounds good, I think the impact is
rather limited. Considering the low number of active contributors in the
project, I'm not sure if anyone will step up to actually implement this,
sorry.

On the other hand, this is a REALLY good place to start if you would like
to get involved in Subversion development. A patch would be more than
welcome on d...@subversion.apache.org.

I took a quick look at the code and I think the error comes from the call
to serf_connection_create2() in /subversion/libsvn_ra_serf/serf.c (see
[1]). You probably need to create a new error code and then check for this
error code in /subversion/libsvn_ra/ra_loader.c (see [2]).

Kind regards,
Daniel

[1]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/serf.c?revision=1905955=markup#l567
[2]
https://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra/ra_loader.c?revision=1905955=markup#l390

RE: SVN Desktopversion

[Jans, Ullrich]

Hi,

das ist ziemlich sicher nicht der richtige Kanal. Der Absenderadresse nach ist 
das ein von der Volkswagen IT verwaltetes Geraet, vielleicht da mal ein Ticket 
aufmachen und nachfragen. 

Gruss, Ulli

From: tg.freigmbh.de via users 
Sent: Friday, April 12, 2024 11:34 AM
To: Kramer, Ricarda (EXTERN: Akkodis) ; 
users@subversion.apache.org
Subject: AW: SVN Desktopversion

CAUTION: This email originated from outside of the Elektrobit organization. Do 
not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hallo,

Die Fehlermeldung besagt das „Tortoise“ nicht mehr funktioniert. Tortoise svn 
ist nicht dasselbe wie apache svn, deswegen ist das hier eigentlich nicht der 
richtige Kanal 
Der wahrscheinlichste fix ist aber „Tortoise svn“ dann neu runterzuladen zu 
installieren.

Viele Grüße, Thorsten
Von: Kramer, Ricarda (EXTERN: Akkodis) 
mailto:extern.ricarda.kra...@volkswagen.de>>
Gesendet: Friday, 12 April 2024 09:30
An: users@subversion.apache.org
Betreff: SVN Desktopversion


Hallo,

seit heute funktioniert meine Desktop-Version von SVN nicht mehr und ich weiß 
nicht warum.

Wenn ich das Programm öffnen möchte, kommt folgende Meldung:
[cid:image001.png@01DA8CD8.D1F61180]

[cid:image002.png@01DA8CD8.D1F61180]

Ich habe nichts gelöscht oder irgendwas verschoben, daher wundere ich mich.
Können Sie mir bei der Behebung des Problems helfen?

Mit freundlichen Grüßen

Ricarda Kramer
Software Projektleitung Leistungselektronik
Im Auftrag der Volkswagen Aktiengesellschaft
EAEL/3

Tel. +49 151 746 315 90

Im Rahmen des zwischen der Volkswagen AG und der AKKODIS Industry Consulting 
GmbH bestehenden Vertragsverhältnisses wende ich mich mit obenstehendem 
Anliegen an Sie. Wenn Sie weitere Fragen haben sollten, können Sie sich 
jederzeit an Herrn Lars Goltermann - Partnerfirmen-Koordinator 
(lars.golterm...@akkodis.com) oder an Herr 
Dr. Lucas Mathusall (EAEL/3) 
(lucas.mathus...@volkswagen.de) wenden.

INTERNAL



INTERNAL

AW: SVN Desktopversion

[tg.freigmbh.de via users]

Hallo,

Die Fehlermeldung besagt das „Tortoise“ nicht mehr funktioniert. Tortoise svn 
ist nicht dasselbe wie apache svn, deswegen ist das hier eigentlich nicht der 
richtige Kanal 
Der wahrscheinlichste fix ist aber „Tortoise svn“ dann neu runterzuladen zu 
installieren.

Viele Grüße, Thorsten
Von: Kramer, Ricarda (EXTERN: Akkodis) 
Gesendet: Friday, 12 April 2024 09:30
An: users@subversion.apache.org
Betreff: SVN Desktopversion


Hallo,

seit heute funktioniert meine Desktop-Version von SVN nicht mehr und ich weiß 
nicht warum.

Wenn ich das Programm öffnen möchte, kommt folgende Meldung:
[cid:image001.png@01DA8CCD.5B4258B0]

[cid:image002.png@01DA8CCD.5B4258B0]

Ich habe nichts gelöscht oder irgendwas verschoben, daher wundere ich mich.
Können Sie mir bei der Behebung des Problems helfen?

Mit freundlichen Grüßen

Ricarda Kramer
Software Projektleitung Leistungselektronik
Im Auftrag der Volkswagen Aktiengesellschaft
EAEL/3

Tel. +49 151 746 315 90

Im Rahmen des zwischen der Volkswagen AG und der AKKODIS Industry Consulting 
GmbH bestehenden Vertragsverhältnisses wende ich mich mit obenstehendem 
Anliegen an Sie. Wenn Sie weitere Fragen haben sollten, können Sie sich 
jederzeit an Herrn Lars Goltermann - Partnerfirmen-Koordinator 
(lars.golterm...@akkodis.com) oder an Herr 
Dr. Lucas Mathusall (EAEL/3) 
(lucas.mathus...@volkswagen.de) wenden.

INTERNAL



INTERNAL

SVN Desktopversion

[Kramer, Ricarda (EXTERN: Akkodis)]

Hallo,

seit heute funktioniert meine Desktop-Version von SVN nicht mehr und ich weiß 
nicht warum.

Wenn ich das Programm öffnen möchte, kommt folgende Meldung:
[cid:image001.png@01DA8CBB.48CE65F0]

[cid:image002.png@01DA8CBB.F7BD4400]

Ich habe nichts gelöscht oder irgendwas verschoben, daher wundere ich mich.
Können Sie mir bei der Behebung des Problems helfen?

Mit freundlichen Grüßen

Ricarda Kramer
Software Projektleitung Leistungselektronik
Im Auftrag der Volkswagen Aktiengesellschaft
EAEL/3

Tel. +49 151 746 315 90

Im Rahmen des zwischen der Volkswagen AG und der AKKODIS Industry Consulting 
GmbH bestehenden Vertragsverhältnisses wende ich mich mit obenstehendem 
Anliegen an Sie. Wenn Sie weitere Fragen haben sollten, können Sie sich 
jederzeit an Herrn Lars Goltermann - Partnerfirmen-Koordinator 
(lars.golterm...@akkodis.com) oder an Herr 
Dr. Lucas Mathusall (EAEL/3) 
(lucas.mathus...@volkswagen.de) wenden.


INTERNAL



INTERNAL

Feature request: distinguish between disconnect to server and to proxy

[Mikhail Dvorkin]

I received this error when doing 'svn update':

svn: E170013: Unable to connect to a repository at URL …

I spent many minutes trying to find why the perfectly working server
would not grant a connection.

The solution was: for years in my TortoiseSVN settings a proxy server
was selected, and it simply has been working until it happened to be
turned off.

So I ask for one of two features:

A) When "unable to connect to a server", make an extra check whether
it is possible to connect to the proxy server (if one is selected). If
this is the case, make the error more verbose, like:

svn: E170013: Unable to connect to a repository at URL …, also unable
to connect to a proxy …

B) Simply make the error message more verbose if the proxy server is
selected in the settings, like:

svn: E170013: Unable to connect to a repository at URL …
(Note: proxy … was used for connection)

Participate in the ASF 25th Anniversary Campaign

[Brian Proffitt]

Hi everyone,

As part of The ASF’s 25th anniversary campaign[1], we will be celebrating
projects and communities in multiple ways.

We invite all projects and contributors to participate in the following
ways:

* Individuals - submit your first contribution:
https://news.apache.org/foundation/entry/the-asf-launches-firstasfcontribution-campaign
* Projects - share your public good story:
https://docs.google.com/forms/d/1vuN-tUnBwpTgOE5xj3Z5AG1hsOoDNLBmGIqQHwQT6k8/viewform?edit_requested=true
* Projects - submit a project spotlight for the blog:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278466116
* Projects - contact the Voice of Apache podcast (formerly Feathercast) to
be featured: https://feathercast.apache.org/help/
*  Projects - use the 25th anniversary template and the #ASF25Years hashtag
on social media:
https://docs.google.com/presentation/d/1oDbMol3F_XQuCmttPYxBIOIjRuRBksUjDApjd8Ve3L8/edit#slide=id.g26b0919956e_0_13

If you have questions, email the Marketing & Publicity team at
mark...@apache.org.

Peace,
BKP

[1] https://apache.org/asf25years/

[NOTE: You are receiving this message because you are a contributor to an
Apache Software Foundation project. The ASF will very occasionally send out
messages relating to the Foundation to contributors and members, such as
this one.]

Brian Proffitt
VP, Marketing & Publicity
VP, Conferences

Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[EML]

I've written a proof-of-concept script which fetches a file from a 
protected svn repo, and posted it on the dev list 
. With 
a bit of luck, this might get someone interested in adding the OAuth2 
code to svn and TSVN.


-Evan

On 30/03/2024 13:40, EML wrote:


Hi Thomas/Daniel/etc. First, standard disclaimer: this isn't my day 
job, and I'm still new to OIDC, so apologies if any of this is 
wrong/too obvious/whatever. On your points:



(1) HTTP requests need to specify 'Authorization: Bearer' with an access
token.

Are you sure mod_openidc accepts a Bearer token when configured with AuthType 
openid-connect?


openid-connect is the only OIDC AuthType (the AuthTypes aren't 
properly documented, which doesn't help).


I think there may be some confusion here, though (TL;DR: bearer tokens 
must be used, and not cookies).


Why? If I just use a browser to connect to an OAuth2-protected 
resource which is on a server behind Apache/mod_auth_openidc ('MAO'), 
/then I never need, or even see, a bearer token/. The reason is that 
this is handled internally by MAO. When I first browse to a protected 
resource, MAO sees that I don't have a session cookie, and connects to 
the identity provider (which it normally finds from 
'OIDCProviderMetadataURL'). MAO then pops ups a login window at the 
provider (the 'IdP', ie. Google/github/whatever); the provider then 
authenticates and redirects back to MAO. If this works out, MAO sends 
back my requested page, /plus a session cookie/. My browser then uses 
this session cookie to communicate with the server; it doesn't need 
the bearer token.


/But/: this isn't how command-line access would work. Something (GCM, 
for the sake of argument) connects /directly/ to the identity provider 
(see the 'credential' section in my first post, which tells GCM how to 
do this). GCM needs to talk to a 'client' at the IdP (more on this 
below). It pops up a login window, goes through a token swap 
procedure, and gets a JWT token if successful. GCM now has a token 
that it can use to communicate with MAO on my server. This next bit 
I'm a bit hazy on, because I've only done minimal testing with GCM. 
However, I presume that MAO then uses the JWT from the browser to 
communicate back to the IdP to check the token validity (or maybe it 
just uses the IdP's known public key to decode the JWT, and then 
assumes that it's valid), and then sends me back a session cookie, 
just like it does for normal web access.


Note, of course, that we cannot assume that the server with the 
protected repo will be running MAO. Frameworks (Tomcat/etc) generally 
have their own way to do this (but it's probably safe to assume that 
most people who have an svn repo will use MAO). All we know for sure 
is that the repo is OAuth2-protected (OIDC, to be precise), and we 
have to use the OAuth2 specs. RFC6750 
 says in the  abstract 
that "/This specification describes how to use bearer tokens in HTTP 
requests to access OAuth 2.0 protected resources.  Any party in 
possession of a bearer token (a "bearer") can use it to get access to 
the associated resources (without demonstrating possession of a 
cryptographic key)./" So, bearer tokens must be used. You can put the 
token in a cookie, but you then have to create an agreed name for that 
cookie, and I can't imagine that anyone does that. I think the cookie 
confusion is to do with session cookies.


However, I think this all pretty moot in out case, unless 
you/we/someone intends to re-invent the wheel and write a version of 
GCM/git-credential-oauth/oidc-agent/whatever. I've got some time today 
and I'm going to try to install oidc-agent and connect through to a 
protected svn repo. If I can come up with a 'manual' procedure then 
this could be coded up in svn.


This is not the approach we have taken (*due to complexity and uncertainty related to protecting the app 
registration client-secret*). We let mod_openidc handle as much complexity as possible.


The client secret is interesting. There are 2 client types 
 defined in 
the RFC: confidential, and public. They differ in how secure the 
client credentials are (not the credentials of the user trying to log 
in; the credentials the client app needs to talk to the OAuth server). 
You would think that we're taking about a public client here: lots of 
people on different computers are trying to access the repo, all using 
the same app credentials. But, in fact, everyone's agreed that this 
sort of CLI client, carrying out machine to machine (M2M) 
communication, is a confidential client. This means that your app (the 
thing we're talking about writing here, ie. 'oidc-svn'/whatever) must 
use a client secret to talk to the OAuth server. The server uses this 
to determine whether the app is authorised to talk to the API. This 
means that you 

Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[EML]

Hi Thomas/Daniel/etc. First, standard disclaimer: this isn't my day job, 
and I'm still new to OIDC, so apologies if any of this is wrong/too 
obvious/whatever. On your points:



(1) HTTP requests need to specify 'Authorization: Bearer' with an access
token.

Are you sure mod_openidc accepts a Bearer token when configured with AuthType 
openid-connect?


openid-connect is the only OIDC AuthType (the AuthTypes aren't properly 
documented, which doesn't help).


I think there may be some confusion here, though (TL;DR: bearer tokens 
must be used, and not cookies).


Why? If I just use a browser to connect to an OAuth2-protected resource 
which is on a server behind Apache/mod_auth_openidc ('MAO'), /then I 
never need, or even see, a bearer token/. The reason is that this is 
handled internally by MAO. When I first browse to a protected resource, 
MAO sees that I don't have a session cookie, and connects to the 
identity provider (which it normally finds from 
'OIDCProviderMetadataURL'). MAO then pops ups a login window at the 
provider (the 'IdP', ie. Google/github/whatever); the provider then 
authenticates and redirects back to MAO. If this works out, MAO sends 
back my requested page, /plus a session cookie/. My browser then uses 
this session cookie to communicate with the server; it doesn't need the 
bearer token.


/But/: this isn't how command-line access would work. Something (GCM, 
for the sake of argument) connects /directly/ to the identity provider 
(see the 'credential' section in my first post, which tells GCM how to 
do this). GCM needs to talk to a 'client' at the IdP (more on this 
below). It pops up a login window, goes through a token swap procedure, 
and gets a JWT token if successful. GCM now has a token that it can use 
to communicate with MAO on my server. This next bit I'm a bit hazy on, 
because I've only done minimal testing with GCM. However, I presume that 
MAO then uses the JWT from the browser to communicate back to the IdP to 
check the token validity (or maybe it just uses the IdP's known public 
key to decode the JWT, and then assumes that it's valid), and then sends 
me back a session cookie, just like it does for normal web access.


Note, of course, that we cannot assume that the server with the 
protected repo will be running MAO. Frameworks (Tomcat/etc) generally 
have their own way to do this (but it's probably safe to assume that 
most people who have an svn repo will use MAO). All we know for sure is 
that the repo is OAuth2-protected (OIDC, to be precise), and we have to 
use the OAuth2 specs. RFC6750 
 says in the  abstract 
that "/This specification describes how to use bearer tokens in HTTP 
requests to access OAuth 2.0 protected resources.  Any party in 
possession of a bearer token (a "bearer") can use it to get access to 
the associated resources (without demonstrating possession of a 
cryptographic key)./" So, bearer tokens must be used. You can put the 
token in a cookie, but you then have to create an agreed name for that 
cookie, and I can't imagine that anyone does that. I think the cookie 
confusion is to do with session cookies.


However, I think this all pretty moot in out case, unless you/we/someone 
intends to re-invent the wheel and write a version of 
GCM/git-credential-oauth/oidc-agent/whatever. I've got some time today 
and I'm going to try to install oidc-agent and connect through to a 
protected svn repo. If I can come up with a 'manual' procedure then this 
could be coded up in svn.


This is not the approach we have taken (*due to complexity and uncertainty related to protecting the app 
registration client-secret*). We let mod_openidc handle as much complexity as possible.


The client secret is interesting. There are 2 client types 
 defined in 
the RFC: confidential, and public. They differ in how secure the client 
credentials are (not the credentials of the user trying to log in; the 
credentials the client app needs to talk to the OAuth server). You would 
think that we're taking about a public client here: lots of people on 
different computers are trying to access the repo, all using the same 
app credentials. But, in fact, everyone's agreed that this sort of CLI 
client, carrying out machine to machine (M2M) communication, is a 
confidential client. This means that your app (the thing we're talking 
about writing here, ie. 'oidc-svn'/whatever) must use a client secret to 
talk to the OAuth server. The server uses this to determine whether the 
app is authorised to talk to the API. This means that you have to suck 
it up and protect the client secret. See this SO answer 
 for tips (note that the 
'HansZ' referred to is the author of MAO).


If you see my original .gitconfig in this thread you'll see that the 
client secret is completely /un/protected - it is (or would be) in 

RE: Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[Thomas Åkesson]

Hi Evan and Daniel,

We are running with mod_openidc in production since late 2022. This includes 
some elaborate apache configs to allow both browsers and Subversion clients to 
access the same URLs protected by AuthType openid-connect (session cookie). 
This works in combination with an installed application containing our code 
that performs the OpenIDC authentication (perhaps similar to GCM, not sure) and 
provides that session token to the Svn client. It would be very interesting to 
make some enhancements to the Subversion client to simplify the setup.

> This all works with git, using Git Credential Manager
>  (GCM; this is
> a cross-platform .NET Core app).


Thanks for mentioning GCM, perhaps worth investigating.

> The repo runs behind Apache httpd, which is using mod_auth_openidc. The
> config file sets 'AuthType openid-connect', and 'Require valid-user'.

> (1) HTTP requests need to specify 'Authorization: Bearer' with an access
> token.

Are you sure mod_openidc accepts a Bearer token when configured with AuthType 
openid-connect?

> If you don't have an access token, something (a script, GCM,
> whatever) has to pop up a browser window and connect to an OAuth2
> identity provider (IdP). The user then logs in (with MFA if configured),
> and the IdP then redirects back to localhost with a token.

This is not the approach we have taken (due to complexity and uncertainty 
related to protecting the app registration client-secret). We let mod_openidc 
handle as much complexity as possible.

> This means
> that the 'script' must also run a webserver to extract the token, which
> it can then add to the GET/POST/whatever request. 

We avoid this temporary webserver by redirecting to an application URL-prefix 
registered in the OS. It is valid to register application URLs as returnUri 
when registering an OpenIDC application with the IdP (but that's not quite how 
we are doing it though...). The temporary "code" in the code flow is shipped to 
the application via the URL-prefix. The application then exchanges the code for 
the session token.

>  1. Why "tunnel the session token in basic auth"? 

Because we are in production since late 2022 and we have to use some 
authentication mechanism that the Subversion clients currently support.

> Does he want HTTP basic auth /and/ HTTPS mod_openidc_module? 

No.

> How does a session token fit in with basic anyway?

We are tunneling the session cookie from mod_openidc as the password part of 
Basic Auth. The Basic auth username is not important because mod_openidc will 
figure it out from the session. I developed some Apache black magic to 
transform the basic auth password into a cookie consumed by mod_openidc. This 
black magic can be removed if the Svn client is enhanced with some Cookie 
support.


>  2. I don't quite understand the 'svn auth' comments - is Thomas
> suggesting /manually/ recording tokens and cookies?

If we have an application/script that performs authentication, it could make 
the session token available to the Svn client via the "svn auth" subcommand 
(with some enhancements). Or it can just run "svn info https:/... --token ..." 
in order to insert it into the Svn client auth cache (with some small 
enhancements).

>  3. Any solution must have bearer tokens /and/ cookies - but that's
> obvious,  so presumably I've misunderstood the post

I would say bearer tokens OR cookies. The decision btw those 2 options is a 
very fundamental design decision. I opted for minimal complexity -> Cookie. 
With different trade-offs one could potentially end up preferring bearer tokens 
but the client-secret and complex client configurations need to be figured out 
(we want to be able to deploy to hundreds of extremely non-technical users).


Best regards,
Thomas Åkesson

Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[EML]

Wow - interesting. I don't know anything about TortoiseSVN, but 
presumably it will 'just work' if svn itself can be fixed up. Daniel - 
if you move everything to dev, I'll follow there.


Thoughts about TA's post:

1. Why "tunnel the session token in basic auth"? Does he want HTTP
   basic auth /and/ HTTPS mod_openidc_module? How does a session token
   fit in with basic anyway?
2. I don't quite understand the 'svn auth' comments - is Thomas
   suggesting /manually/ recording tokens and cookies?
3. Any solution must have bearer tokens /and/ cookies - but that's
   obvious,  so presumably I've misunderstood the post

On the callback: this has to be caught by a webserver which is initiated 
by svn, not TSVN, or command-line svn couldn't use OIDC. TSVN doesn't 
need to know anything about any of this. But, as I said, I know nothing 
about TSVN so I may be wrong. If TSVN actually makes curl requests to 
the server, for example, then it would need to know.


Thomas has obviously done a lot of work, but another option is to port 
GCM. This does exactly what is required, except that it interacts with 
its own credentials manager and not svn's, and there are hooks from git 
which need to be replaced. Command-line OAuth2/OIDC would be generically 
useful, so it would be a pity to do this work just for svn. However, GCM 
is written in C#, on .NET Core, and I know nothing about C# or the .NET 
runtime (I do C++/Linux). I think dotnet can be fiddly to get running on 
Linux (I've only tested GCM on Windows).


Another option is to integrate oidc-agent 
. This has less baggage than 
GCM, and is written in C. It's straightforward, and well-documented, and 
is a good place to get some understanding of what command-line OIDC is. 
I looked at this last month but didn't have the time to go any further. 
The developer/s are academic (kit.edu ) and, I 
think, would be interested in this. I have a bit more time now so I'll 
have another look at this.


-Evan

On 29/03/2024 15:46, Daniel Sahlberg wrote:
Den fre 29 mars 2024 kl 16:27 skrev EML >:


Before I do too much work on this, I'd like to do a sanity check.
Does anyone know of a client which will access a repo over HTTPS,
with an access/bearer token? This gives SSO and multi-factor
authentication using OAuth2.

The repo runs behind Apache httpd, which is using
mod_auth_openidc. The config file sets 'AuthType openid-connect',
and 'Require valid-user'. The repos additionally require a
specific claim to access them ('Require claim x:y:z').

This all works with git, using Git Credential Manager
 (GCM;
this is a cross-platform .NET Core app).

Basically, two things need to be done:

(1) HTTP requests need to specify 'Authorization: Bearer' with an
access token. If you don't have an access token, something (a
script, GCM, whatever) has to pop up a browser window and connect
to an OAuth2 identity provider (IdP). The user then logs in (with
MFA if configured), and the IdP then redirects back to localhost
with a token. This means that the 'script' must also run a
webserver to extract the token, which it can then add to the
GET/POST/whatever request.

(2) Subversion has to know about this in some way, and has to run
the script to use a previously-generated token, or request a new
one if necessary.

The first step is not, I think, particularly difficult, and there
are various existing scripts or apps out there that do some or all
of the problem. GCM itself looks pretty complex. I'm not really
sure what the complexity is. The choice to use .NET doesn't help
(but it has to be multi-platform), but a lot of the complexity is
presumably in how to use the credential manager to store tokens.
There's also some complexity in handling different targets
(GitHub, Bitbucket, Azure, whatever). However, there is a generic
setup (which I use; this talks to Keycloak). My entire config
(.gitconfig) to talk to Keycloak looks this:

[credential]
    helper = cache --timeout 7200
    helper = "oauth"

[credential ""]
    oauthScopes   = "openid email"
    oauthAuthURL  =
/keycloak/realms//protocol/openid-connect/auth
    oauthTokenURL =
/keycloak/realms//protocol/openid-connect/token
    oauthClientId = openid-cli
    oauthRedirectUri  = http://127.0.0.1
    oauthClientSecret = 


This was actually discussed over on the TortoiseSVN dev list today in 
the following thread 
https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8


I think the steps outlined by Thomas Åkerström is quite similar to 
what you are also suggesting.


This should probably be discussed further on d...@subversion.apache.org.

Kind regards,
Daniel

Re: Repo access with HTTPS and an access token (or: GCM for svn?)

[Daniel Sahlberg]

Den fre 29 mars 2024 kl 16:27 skrev EML :

> Before I do too much work on this, I'd like to do a sanity check. Does
> anyone know of a client which will access a repo over HTTPS, with an
> access/bearer token? This gives SSO and multi-factor authentication using
> OAuth2.
>
> The repo runs behind Apache httpd, which is using mod_auth_openidc. The
> config file sets 'AuthType openid-connect', and 'Require valid-user'. The
> repos additionally require a specific claim to access them ('Require claim
> x:y:z').
>
> This all works with git, using Git Credential Manager
>  (GCM; this is a
> cross-platform .NET Core app).
>
> Basically, two things need to be done:
>
> (1) HTTP requests need to specify 'Authorization: Bearer' with an access
> token. If you don't have an access token, something (a script, GCM,
> whatever) has to pop up a browser window and connect to an OAuth2 identity
> provider (IdP). The user then logs in (with MFA if configured), and the IdP
> then redirects back to localhost with a token. This means that the 'script'
> must also run a webserver to extract the token, which it can then add to
> the GET/POST/whatever request.
>
> (2) Subversion has to know about this in some way, and has to run the
> script to use a previously-generated token, or request a new one if
> necessary.
>
> The first step is not, I think, particularly difficult, and there are
> various existing scripts or apps out there that do some or all of the
> problem. GCM itself looks pretty complex. I'm not really sure what the
> complexity is. The choice to use .NET doesn't help (but it has to be
> multi-platform), but a lot of the complexity is presumably in how to use
> the credential manager to store tokens. There's also some complexity in
> handling different targets (GitHub, Bitbucket, Azure, whatever). However,
> there is a generic setup (which I use; this talks to Keycloak). My entire
> config (.gitconfig) to talk to Keycloak looks this:
>
> [credential]
> helper = cache --timeout 7200
> helper = "oauth"
>
> [credential ""]
> oauthScopes   = "openid email"
> oauthAuthURL  =
> /keycloak/realms//protocol/openid-connect/auth
> oauthTokenURL =
> /keycloak/realms//protocol/openid-connect/token
> oauthClientId = openid-cli
> oauthRedirectUri  = http://127.0.0.1
> oauthClientSecret = 
>

This was actually discussed over on the TortoiseSVN dev list today in the
following thread https://groups.google.com/g/tortoisesvn-dev/c/ByECclvGKi8

I think the steps outlined by Thomas Åkerström is quite similar to what you
are also suggesting.

This should probably be discussed further on d...@subversion.apache.org.

Kind regards,
Daniel

Repo access with HTTPS and an access token (or: GCM for svn?)

[EML]

Before I do too much work on this, I'd like to do a sanity check. Does 
anyone know of a client which will access a repo over HTTPS, with an 
access/bearer token? This gives SSO and multi-factor authentication 
using OAuth2.


The repo runs behind Apache httpd, which is using mod_auth_openidc. The 
config file sets 'AuthType openid-connect', and 'Require valid-user'. 
The repos additionally require a specific claim to access them ('Require 
claim x:y:z').


This all works with git, using Git Credential Manager 
 (GCM; this is 
a cross-platform .NET Core app).


Basically, two things need to be done:

(1) HTTP requests need to specify 'Authorization: Bearer' with an access 
token. If you don't have an access token, something (a script, GCM, 
whatever) has to pop up a browser window and connect to an OAuth2 
identity provider (IdP). The user then logs in (with MFA if configured), 
and the IdP then redirects back to localhost with a token. This means 
that the 'script' must also run a webserver to extract the token, which 
it can then add to the GET/POST/whatever request.


(2) Subversion has to know about this in some way, and has to run the 
script to use a previously-generated token, or request a new one if 
necessary.


The first step is not, I think, particularly difficult, and there are 
various existing scripts or apps out there that do some or all of the 
problem. GCM itself looks pretty complex. I'm not really sure what the 
complexity is. The choice to use .NET doesn't help (but it has to be 
multi-platform), but a lot of the complexity is presumably in how to use 
the credential manager to store tokens. There's also some complexity in 
handling different targets (GitHub, Bitbucket, Azure, whatever). 
However, there is a generic setup (which I use; this talks to Keycloak). 
My entire config (.gitconfig) to talk to Keycloak looks this:


[credential]
    helper = cache --timeout 7200
    helper = "oauth"

[credential ""]
    oauthScopes   = "openid email"
    oauthAuthURL  = 
/keycloak/realms//protocol/openid-connect/auth
    oauthTokenURL = 
/keycloak/realms//protocol/openid-connect/token

    oauthClientId = openid-cli
    oauthRedirectUri  = http://127.0.0.1
    oauthClientSecret = 

Community Over Code NA 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

[ You are receiving this email as a subscriber to one or more ASF project
dev or user
  mailing lists and is not being sent to you directly. It is important that
we reach all of our
  users and contributors/committers so that they may get a chance to
benefit from this.
  We apologise in advance if this doesn't interest you but it is on topic
for the mailing
  lists of the Apache Software Foundation; and it is important please that
you do not
  mark this as spam in your email client. Thank You! ]

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code NA 2024 are now
open!

We will be supporting Community over Code NA, Denver Colorado in
October 7th to the 10th 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this years applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Monday 6th May, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Denver, Colorado , October 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 1:04 PM Stanley Gilliam
 wrote:
>
> If I am understanding correctly, we need to add something like:
> 1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
>   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA
>
> to which config file? Apologies I did not set up the server so I'm learning 
> this as we go.

Assuming you are using Apache... Here's what one of ours looks like
for cryptopp.com web server (we don't run SVN on this server, but it
illustrates a TLS configuration). And we are using Ubuntu, not CentOS
or Red Hat (we had to get away from that antique software RH
provides).

>From 
>:

SSLCertificateFile /etc/ssl/private/cryptopp-com.cert.pem
SSLCertificateKeyFile /etc/ssl/private/cryptopp-com.key.pem
SSLCertificateChainFile /etc/ssl/private/cryptopp-com.chain.pem

The files are what you would expect.

   * SSLCertificateFile is the web server's certificate
   * SSLCertificateKeyFile is the private key for the public key in
the certificate
   * SSLCertificateChainFile is the collection of intermediate
certificates for chain validation

Apache knows what to do with them.

Here is the chain file. Notice we do not include the Let's Encrypt
Root CA since clients are expected to have it and trust it:

# cat /etc/ssl/private/cryptopp-com.chain.pem

# Let's Encrypt Authority R3
-BEGIN CERTIFICATE-
MIIFFjCCAv6gAwIBAgIRAJErCErPDBinU/bWLiWnX1owDQYJKoZIhvcNAQELBQAw
TzELMAkGA1UEBhMCVVMxKTAnBgNVBAoTIEludGVybmV0IFNlY3VyaXR5IFJlc2Vh
cmNoIEdyb3VwMRUwEwYDVQQDEwxJU1JHIFJvb3QgWDEwHhcNMjAwOTA0MDAwMDAw
WhcNMjUwOTE1MTYwMDAwWjAyMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNTGV0J3Mg
RW5jcnlwdDELMAkGA1UEAxMCUjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQC7AhUozPaglNMPEuyNVZLD+ILxmaZ6QoinXSaqtSu5xUyxr45r+XXIo9cP
R5QUVTVXjJ6oojkZ9YI8QqlObvU7wy7bjcCwXPNZOOftz2nwWgsbvsCUJCWH+jdx
sxPnHKzhm+/b5DtFUkWWqcFTzjTIUu61ru2P3mBw4qVUq7ZtDpelQDRrK9O8Zutm
NHz6a4uPVymZ+DAXXbpyb/uBxa3Shlg9F8fnCbvxK/eG3MHacV3URuPMrSXBiLxg
Z3Vms/EY96Jc5lP/Ooi2R6X/ExjqmAl3P51T+c8B5fWmcBcUr2Ok/5mzk53cU6cG
/kiFHaFpriV1uxPMUgP17VGhi9sVAgMBAAGjggEIMIIBBDAOBgNVHQ8BAf8EBAMC
AYYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMBMBIGA1UdEwEB/wQIMAYB
Af8CAQAwHQYDVR0OBBYEFBQusxe3WFbLrlAJQOYfr52LFMLGMB8GA1UdIwQYMBaA
FHm0WeZ7tuXkAXOACIjIGlj26ZtuMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcw
AoYWaHR0cDovL3gxLmkubGVuY3Iub3JnLzAnBgNVHR8EIDAeMBygGqAYhhZodHRw
Oi8veDEuYy5sZW5jci5vcmcvMCIGA1UdIAQbMBkwCAYGZ4EMAQIBMA0GCysGAQQB
gt8TAQEBMA0GCSqGSIb3DQEBCwUAA4ICAQCFyk5HPqP3hUSFvNVneLKYY611TR6W
PTNlclQtgaDqw+34IL9fzLdwALduO/ZelN7kIJ+m74uyA+eitRY8kc607TkC53wl
ikfmZW4/RvTZ8M6UK+5UzhK8jCdLuMGYL6KvzXGRSgi3yLgjewQtCPkIVz6D2QQz
CkcheAmCJ8MqyJu5zlzyZMjAvnnAT45tRAxekrsu94sQ4egdRCnbWSDtY7kh+BIm
lJNXoB1lBMEKIq4QDUOXoRgffuDghje1WrG9ML+Hbisq/yFOGwXD9RiX8F6sw6W4
avAuvDszue5L3sz85K+EC4Y/wFVDNvZo4TYXao6Z0f+lQKc0t8DQYzk1OXVu8rp2
yJMC6alLbBfODALZvYH7n7do1AZls4I9d1P4jnkDrQoxB3UqQ9hVl3LEKQ73xF1O
yK5GhDDX8oVfGKF5u+decIsH4YaTw7mP3GFxJSqv3+0lUFJoi5Lc5da149p90Ids
hCExroL1+7mryIkXPeFM5TgO9r0rvZaBFOvV2z0gp35Z0+L4WPlbuEjN/lxPFin+
HlUjr8gRsI3qfJOQFy/9rKIJR0Y/8Omwt/8oTWgy1mdeHmmjk7j1nYsvC9JSQ6Zv
MldlTTKB3zhThV1+XWYp6rjd5JW1zbVWEkLNxE7GJThEUG3szgBVGP7pSWTUTsqX
nLRbwHOoq7hHwg==
-END CERTIFICATE-

You can use the same openssl commands to finger our web server (or any
other well configured server). In fact, once I change a configuration
(like with the quarterly end entity certificate update), I test using
SSL Labs: 
.

Jeff

Re: SVN does not trust cert

[Stanley Gilliam via users]

Would it be OpenSSL.conf?

Get Outlook for iOS

From: Stanley Gilliam 
Sent: Monday, March 25, 2024 1:04:11 PM
To: noloa...@gmail.com 
Cc: Daniel Sahlberg ; users@subversion.apache.org 

Subject: RE: SVN does not trust cert

Hi Jeff,

If I am understanding correctly, we need to add something like:
1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
  i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA

to which config file? Apologies I did not set up the server so I'm learning 
this as we go.


Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Jeffrey Walton 
Sent: Monday, March 25, 2024 12:34 PM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam  
wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform
> PEM -text -noout unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect
> hpc.gsk.com:443 -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo
> Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress =
> scientific_computing_supp...@gsk.com
> verify error:num=20:unable to get local issuer certificate verify
> return:1
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo
> Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress =
> scientific_computing_supp...@gsk.com
> verify error:num=21:unable to verify the first certificate verify
> return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 -BEGIN
> CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
> dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
> aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
> A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
> UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
> BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
> bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
> AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
> W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
> AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
> /bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
> 0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
> MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
> BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
> HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
> 0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
> LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
> ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
> c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
> b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
> NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
> FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
> AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
> SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
> ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
> v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
> RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
> pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
> W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
> O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
> us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
> XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
> RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
> GzKWlw6feJiNivlqBH1QwP39
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_support
> @gsk.com issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 2361 bytes and written 447 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public
> key is 2048 bit Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN 

RE: SVN does not trust cert

[Stanley Gilliam via users]

Hi Jeff,

If I am understanding correctly, we need to add something like:
1 s:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
  i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Root CA

to which config file? Apologies I did not set up the server so I'm learning 
this as we go.


Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Jeffrey Walton 
Sent: Monday, March 25, 2024 12:34 PM
To: Stanley Gilliam 
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam  
wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform
> PEM -text -noout unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect
> hpc.gsk.com:443 -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo
> Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress =
> scientific_computing_supp...@gsk.com
> verify error:num=20:unable to get local issuer certificate verify
> return:1
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo
> Smith Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress =
> scientific_computing_supp...@gsk.com
> verify error:num=21:unable to verify the first certificate verify
> return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1 -BEGIN
> CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
> dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
> aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
> A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
> UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
> BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
> bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
> AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
> W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
> AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
> /bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
> 0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
> MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
> BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
> HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
> 0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
> LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
> ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
> c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
> b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
> NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
> FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
> AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
> SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
> ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
> v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
> RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
> pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
> W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
> O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
> us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
> XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
> RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
> GzKWlw6feJiNivlqBH1QwP39
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_support
> @gsk.com issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 2361 bytes and written 447 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public
> key is 2048 bit Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 4A9C3A7A8D91D5BE107F514BD64009F30D71C338D3C0E11AD6F8F2BBA256BDFA
> Session-ID-ctx:
> Master-Key: 
> 

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 12:26 PM Stanley Gilliam
 wrote:
>
> Here is the output:
>
> [I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform PEM 
> -text -noout
> unable to load certificate
> 139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start 
> line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE
>
>
> [I am root!@uptus060-1:private]#  openssl s_client -connect hpc.gsk.com:443 
> -servername hpc.gsk.com -showcerts
> CONNECTED(0003)
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith 
> Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = 
> scientific_computing_supp...@gsk.com
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith 
> Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = 
> scientific_computing_supp...@gsk.com
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> -BEGIN CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
> dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
> aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
> A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
> UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
> BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
> bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
> AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
> W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
> AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
> /bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
> 0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
> MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
> BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
> HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
> 0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
> LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
> ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
> c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
> b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
> NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
> FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
> AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
> SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
> ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
> v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
> RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
> pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
> W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
> O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
> us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
> XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
> RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
> GzKWlw6feJiNivlqBH1QwP39
> -END CERTIFICATE-
> ---
> Server certificate
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
> issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 2361 bytes and written 447 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> 4A9C3A7A8D91D5BE107F514BD64009F30D71C338D3C0E11AD6F8F2BBA256BDFA
> Session-ID-ctx:
> Master-Key: 
> 4B6426694B33A96B96BD3B382D7266826F1FC80C0B4857A9953AE969E6AB903B44739603E06D1933E269DCFA5D30CFD9
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> TLS session ticket lifetime hint: 7200 (seconds)
> TLS session ticket:
>  - 25 98 6a 95 45 08 1d 16-50 d9 fa 27 98 8f a3 9f   %.j.E...P..'
> 0010 - 5e 8f e6 ca a5 05 be ea-e5 e7 00 8d da 8f 10 0a   ^...
> 0020 - 0c d2 c2 94 ca eb 06 74-46 a1 00 5f 97 b3 aa f1   ...tF.._
> 0030 - b7 2a a3 19 84 67 72 5d-13 f9 9f a4 86 4f 98 13   .*...gr].O..
> 0040 - 01 37 

RE: SVN does not trust cert

[Stanley Gilliam via users]

Here is the output:

[I am root!@uptus060-1:private]# echo "$cert" | openssl x509 -inform PEM -text 
-noout
unable to load certificate
139671613519760:error:0906D06C:PEM routines:PEM_read_bio:no start 
line:pem_lib.c:707:Expecting: TRUSTED CERTIFICATE


[I am root!@uptus060-1:private]#  openssl s_client -connect hpc.gsk.com:443 
-servername hpc.gsk.com -showcerts
CONNECTED(0003)
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
-BEGIN CERTIFICATE-
MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
/bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
GzKWlw6feJiNivlqBH1QwP39
-END CERTIFICATE-
---
Server certificate
subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2361 bytes and written 447 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 4A9C3A7A8D91D5BE107F514BD64009F30D71C338D3C0E11AD6F8F2BBA256BDFA
Session-ID-ctx:
Master-Key: 
4B6426694B33A96B96BD3B382D7266826F1FC80C0B4857A9953AE969E6AB903B44739603E06D1933E269DCFA5D30CFD9
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 25 98 6a 95 45 08 1d 16-50 d9 fa 27 98 8f a3 9f   %.j.E...P..'
0010 - 5e 8f e6 ca a5 05 be ea-e5 e7 00 8d da 8f 10 0a   ^...
0020 - 0c d2 c2 94 ca eb 06 74-46 a1 00 5f 97 b3 aa f1   ...tF.._
0030 - b7 2a a3 19 84 67 72 5d-13 f9 9f a4 86 4f 98 13   .*...gr].O..
0040 - 01 37 b1 fa 38 d4 bb 18-9b 8a ef bf 3f c4 3a 5a   .7..8...?.:Z
0050 - be 87 fe 5e 31 35 c5 31-63 16 9c 80 55 78 79 2c   ...^15.1c...Uxy,
0060 - c7 93 45 71 7a 39 7f f3-42 4a 47 85 18 59 22 51   ..Eqz9..BJG..Y"Q
0070 - e9 23 f7 6e a3 9d 35 73-6f 35 cd 

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 12:01 PM Daniel Sahlberg
 wrote:
>
> Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam 
> :
>>
>> Hello,
>>
>> So we use appview to update our certificates and our cert team confirmed 
>> that the cert was updated correctly. Is there another way to possibly verify 
>> this. There may also be something to the second option, I am on a linux RH 
>> OS. Is there a way someone could jump on a short call with us?
>
> What if you run the same command as Jeffrey already tries, ie:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
>
> (I had to Ctrl-D out of the above command). I'm not familiar with openssl 
> debugging but there seems to be a lot of useful information on the 
> certificate chain. Verify that all the intermediary certificates are 
> available and that the root certificate is trusted by your client.

CRTL+D is normal in this situation. OpenSSL is used to create the
secure channel to the application. However, the application (a web
server) is waiting for a command, like GET or POST.

You can sidestep it with something like:

echo -e 'GET / HTTP1.1\r\n\r\n' | openssl s_client ...

That sends a command to the web server. The web server will provide a
response, and then close the connection.

Jeff

RE: SVN does not trust cert

[Stanley Gilliam via users]

Hi,

Did you see the email with the output?

[HPC Admin Host]
[I am root!@uptus060-1:conf.d]# openssl 
s_client -connect hpc.gsk.com:443
CONNECTED(0003)
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = 
scientific_computing_supp...@gsk.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = 
scientific_computing_supp...@gsk.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
Server certificate
-BEGIN CERTIFICATE-
MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
/bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
GzKWlw6feJiNivlqBH1QwP39
-END CERTIFICATE-
subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2341 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: F8C2904FEE4CA89D0F03B21E4D8E16B120419D3F0737265AAC27452DD5BAD62E
Session-ID-ctx:
Master-Key: 
4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE8113248
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 33 fa b8 44 6b 0f fe 61-e5 14 06 66 19 9d 0e 73   3..Dk..a...f...s
   0010 - 8f 06 54 21 20 97 7d ac-2c c4 12 91 c8 c0 c7 7f   ..T! .}.,...
0020 - 09 8a c8 13 0a 58 fc 16-e2 f3 96 67 c6 d6 d5 58   .X.g...X
0030 - ab 60 47 fc 66 22 17 8b-04 73 fd 2d a5 62 c4 35   .`G.f"...s.-.b.5
0040 - e8 dc 3a a9 e6 37 ba 2a-ea 05 0d ea fb 5a 01 80   ..:..7.*.Z..
0050 - 88 9e 6a 5d 7b ae 21 8f-89 32 af ae 0c 52 20 27   ..j]{.!..2...R '
0060 - 2f 1b 8e ae 18 82 54 c0-ee e4 b9 bb 1e 71 

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 11:55 AM Stanley Gilliam
 wrote:
>
> I apologize for the miscommunication. Here is the output from the openssl 
> command:
>
> [I am root!@uptus060-1:conf.d]# openssl s_client -connect hpc.gsk.com:443

You should use -servername here. It triggers Server Name Indication (SNI).

> CONNECTED(0003)
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith 
> Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = 
> scientific_computing_supp...@gsk.com
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith 
> Kline, OU = SRCA, CN = hpc.gsk.com, emailAddress = 
> scientific_computing_supp...@gsk.com
> verify error:num=21:unable to verify the first certificate
> verify return:1
> ---
> Certificate chain
>  0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
>i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> Server certificate
> -BEGIN CERTIFICATE-
> MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
> ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
> dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
> aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
> A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
> UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
> BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
> bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
> AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
> W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
> AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
> /bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
> 0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
> MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
> BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
> HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
> 0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
> LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
> ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
> c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
> b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
> NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
> FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
> AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
> SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
> ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
> v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
> RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
> pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
> W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
> O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
> us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
> XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
> RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
> GzKWlw6feJiNivlqBH1QwP39
> -END CERTIFICATE-
> subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
> Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
> issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
> ---
> No client certificate CA names sent
> Peer signing digest: SHA512
> Server Temp Key: ECDH, P-256, 256 bits
> ---
> SSL handshake has read 2341 bytes and written 427 bytes
> ---
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: 
> F8C2904FEE4CA89D0F03B21E4D8E16B120419D3F0737265AAC27452DD5BAD62E
> Session-ID-ctx:
> Master-Key: 
> 4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE8113248
> Key-Arg   : None
> Krb5 Principal: None
> PSK identity: None
> PSK identity hint: None
> TLS session ticket lifetime hint: 7200 (seconds)
> TLS session ticket:
>  - 33 fa b8 44 6b 0f fe 61-e5 14 06 66 19 9d 0e 73   3..Dk..a...f...s
> 0010 - 8f 06 54 21 20 97 7d ac-2c c4 12 91 c8 c0 c7 7f   ..T! .}.,...
> 0020 - 09 8a c8 13 0a 58 fc 16-e2 f3 96 67 c6 d6 d5 58   .X.g...X
> 0030 - ab 60 47 fc 66 22 17 8b-04 73 fd 2d a5 62 c4 35   .`G.f"...s.-.b.5
> 0040 - e8 dc 3a a9 e6 37 ba 2a-ea 05 0d ea fb 5a 01 80   ..:..7.*.Z..
> 0050 - 88 9e 6a 5d 7b ae 21 8f-89 32 af ae 0c 52 20 27   ..j]{.!..2...R '

RE: SVN does not trust cert

[Stanley Gilliam via users]

Adding @Jung Yi

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

-Original Message-
From: Stanley Gilliam 
Sent: Monday, March 25, 2024 11:55 AM
To: noloa...@gmail.com
Cc: Daniel Sahlberg ; users@subversion.apache.org
Subject: RE: SVN does not trust cert

Ok,

I apologize for the miscommunication. Here is the output from the openssl 
command:

[I am root!@uptus060-1:conf.d]# openssl s_client -connect hpc.gsk.com:443
CONNECTED(0003)
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=20:unable to get local issuer certificate verify return:1
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=21:unable to verify the first certificate verify return:1
---
Certificate chain
 0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
Server certificate
-BEGIN CERTIFICATE-
MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
/bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
GzKWlw6feJiNivlqBH1QwP39
-END CERTIFICATE-
subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2341 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 
2048 bit Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: F8C2904FEE4CA89D0F03B21E4D8E16B120419D3F0737265AAC27452DD5BAD62E
Session-ID-ctx:
Master-Key: 
4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE8113248
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 33 fa b8 44 6b 0f fe 61-e5 14 06 66 19 9d 0e 73   3..Dk..a...f...s
0010 - 8f 06 54 21 20 97 7d ac-2c c4 12 91 c8 c0 c7 7f   ..T! .}.,...
0020 - 09 8a c8 13 0a 58 fc 16-e2 f3 96 67 c6 d6 d5 58   .X.g...X
0030 - ab 60 47 fc 66 22 17 8b-04 73 fd 2d a5 62 c4 35   .`G.f"...s.-.b.5
0040 - e8 dc 3a a9 e6 37 ba 2a-ea 05 0d ea fb 5a 01 80   ..:..7.*.Z..
0050 - 88 9e 6a 5d 7b ae 21 8f-89 32 af ae 0c 52 20 27   ..j]{.!..2...R '
0060 - 

RE: SVN does not trust cert

[Stanley Gilliam via users]

Centos Linux 7.9

Adding @Jung Yi

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

From: Daniel Sahlberg 
Sent: Monday, March 25, 2024 11:17 AM
To: noloa...@gmail.com
Cc: Stanley Gilliam ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton : On 
Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  wrote: > > I am a system admin for GlaxoSmithKline. We are 
currently

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton 
mailto:noloa...@gmail.com>>:
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
mailto:users@subversion.apache.org>> wrote:
>
> I am a system admin for GlaxoSmithKline. We are currently having issues 
> getting our svn instance to authenticate. This all happened after the cert 
> was updated. We are currently getting the message :
>
> svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server 
> certificate verification failed: issuer is not trusted (https://hpc.gsk.com)
>
> The cert was updated correctly we believe because the website works.
>
> is there anybody that may be able to help?

DNS seems to be a problem:

$ openssl s_client -connect hpc.gsk.com:443 -servername 
hpc.gsk.com
40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
lib:../crypto/bio/bio_addr.c:738:Name or service not known
connect:errno=22

And:

$ nslookup hpc.gsk.com
Server: 127.0.0.53
Address:127.0.0.53#53

** server can't find hpc.gsk.com: NXDOMAIN

You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.

It might be that the hpc.gsk.com domain is only available 
on an internal network (ie, on an internal DNS server). If there was a missing 
DNS entry you should get an error message similar to this:

$ svn ls https://hpc.gsk.com
svn: E170013: Unable to connect to a repository at URL 'https://hpc.gsk.com'
svn: E670002: Name or service not known
$

(The missing DNS entry makes it more difficult for someone outside of the 
company to help in debugging of course!).

"issuer is not trusted" sounds to me like it is a self-signed certificate or 
that the certificate is signed by a root that isn't trusted by the client. Can 
you verify that the client really trust the issuer of the certificate?

Another potential explanation (although not supported by the available 
evidence) is that there is a mismatch between the cipher of the new certificate 
compared to what OpenSSL on the client is supporting.

Which platform are you on and what are the versions of Subversion and the 
linked OpenSSL library?

Kind regards,
Daniel


GSK monitors email communications sent to and from GSK in order to protect GSK, 
our employees, customers, suppliers and business partners, from cyber threats 
and loss of GSK Information. GSK monitoring is conducted with appropriate 
confidentiality controls and in accordance with local laws and after 
appropriate consultation.

RE: SVN does not trust cert

[Stanley Gilliam via users]

Ok,

I apologize for the miscommunication. Here is the output from the openssl 
command:

[I am root!@uptus060-1:conf.d]# openssl s_client -connect hpc.gsk.com:443
CONNECTED(0003)
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = US, ST = Pennsylvania, L = Upper Providence, O = Glaxo Smith Kline, 
OU = SRCA, CN = hpc.gsk.com, emailAddress = scientific_computing_supp...@gsk.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
   i:/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
Server certificate
-BEGIN CERTIFICATE-
MIIGbjCCBFagAwIBAgITEQAABQ+0dA0YF873AQAFDzANBgkqhkiG9w0BAQsF
ADBlMRMwEQYKCZImiZPyLGQBGRYDY29tMRgwFgYKCZImiZPyLGQBGRYIY29ycG5l
dDExGTAXBgoJkiaJk/IsZAEZFgl3bXNlcnZpY2UxGTAXBgNVBAMTEEdTSyBJc3N1
aW5nIENBIDEwHhcNMjQwMzA4MTcyMDU1WhcNMjUwMzA4MTcyMDU1WjCBtTELMAkG
A1UEBhMCVVMxFTATBgNVBAgTDFBlbm5zeWx2YW5pYTEZMBcGA1UEBxMQVXBwZXIg
UHJvdmlkZW5jZTEaMBgGA1UEChMRR2xheG8gU21pdGggS2xpbmUxDTALBgNVBAsT
BFNSQ0ExFDASBgNVBAMTC2hwYy5nc2suY29tMTMwMQYJKoZIhvcNAQkBFiRzY2ll
bnRpZmljX2NvbXB1dGluZ19zdXBwb3J0QGdzay5jb20wggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQC1Cr+j9j5/739k+sHHiMDMvhprJmDHazw0UI1rPX7j
W9wPg2kYHnP+jv33j7DB6vE/opCFVOgHTV3Lc7by3QBZAG142GPVSvu51k2syB+r
AooW5a7onwaqZRKRSQX0NkHI4vSRHjVh9/0zxX6aPX6ygDyDKWOPslQ/71SFCyuZ
/bgt/HMXeTP1WaT5u13lj5XtbRejx1WMu3HoRLguXZ6pBa5M5KNc9CaJJcnuTLzm
0152G1As1mkLJ2wm0PqzhXADoqXfnotBvZcSKov4+vYSSFB+7RUVLjdUVkRieDCK
MBsGm+ufxUhWAxXnlC2b9NmM0XV7fr98V8WZD2D2sL4PAgMBAAGjggHEMIIBwDAv
BgNVHREEKDAmggtocGMuZ3NrLmNvbYIXdXB0dXMwNjAtMS5jb3JwbmV0Mi5jb20w
HQYDVR0OBBYEFAVcViHs7XlTuBk8aN7489VTL4pIMB8GA1UdIwQYMBaAFKvPJYEQ
0/UAImqrIU7r9upTKxjpMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9wa2kuZ3Nr
LmNvbS9jZHAvR1NLJTIwSXNzdWluZyUyMENBJTIwMS5jcmwwcgYIKwYBBQUHAQEE
ZjBkMD0GCCsGAQUFBzAChjFodHRwOi8vcGtpLmdzay5jb20vY2RwL0dTSyUyMElz
c3VpbmclMjBDQSUyMDEuY3J0MCMGCCsGAQUFBzABhhdodHRwOi8vcGtpLmdzay5j
b20vb2NzcDAOBgNVHQ8BAf8EBAMCBaAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC
NxUI6vIrg/quQIX1kxyFkoFCheT+WYFUhq3CJ4KPsXwCAWQCAT8wHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMCcGCSsGAQQBgjcVCgQaMBgwCgYIKwYBBQUH
AwEwCgYIKwYBBQUHAwIwDQYJKoZIhvcNAQELBQADggIBAD0zCO/K/11ycaNA3scY
SpT8Tqzc5wJToeC+EEyk+fCbwBaOfoPiDNLUC4jsG8kLtb1Z4XhBMa7eGmz3Xt58
ubVC5C4QW/AJI0v0oJU3atJoPk5h8iERGzolEHnbpvt1dLDpmwFzid6APzavixem
v1FC0jmD2tk5W2HSaMCZ8Qbt8B9uSwyknxLwjc4oyMxs1Oq1Jtsv8HCzC4Bi9yd6
RYbB4uNAvULBSK5RoIjgsONfE42fnJKPCS1TBPWkjlROlmhyvi76NNoPl4GlS+eM
pv9FB+Q7xcYTrfoygvEy6lvPCgQ3AqFcVmbQg5dEBMthPAymBHAdQHkjbKfVJd5X
W8CFmsZ7pD8nmj5lfzT4SpkiMj59U0bj2e8FfLWQybtiGCGFO9M/nZdOHQndxHua
O8bJzWs4rCy9hw+iOHZEUEe06m+mc+rLPN7DTO1rQOAk/BdakIauQyMTh5oYQ2mM
us+7YUwZrNidZv9xfAJZc+zmnaumoGIbxkKChSfwhtb5L8uFnfQc6XDNaYUVKvwi
XV9OQgiymXkGAp8Ai5eVv881BirqQkHyAtbUdpazUF5jlxreowp24NSAa/rWLa6p
RKqS9aPC2lOfR2Kysv1SvJgst1OvtckqKsdlunGxRUH5gInwn7gzzmovCeWiD3+F
GzKWlw6feJiNivlqBH1QwP39
-END CERTIFICATE-
subject=/C=US/ST=Pennsylvania/L=Upper Providence/O=Glaxo Smith 
Kline/OU=SRCA/CN=hpc.gsk.com/emailAddress=scientific_computing_supp...@gsk.com
issuer=/DC=com/DC=corpnet1/DC=wmservice/CN=GSK Issuing CA 1
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 2341 bytes and written 427 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol  : TLSv1.2
Cipher: ECDHE-RSA-AES256-GCM-SHA384
Session-ID: F8C2904FEE4CA89D0F03B21E4D8E16B120419D3F0737265AAC27452DD5BAD62E
Session-ID-ctx:
Master-Key: 
4D6D3D158228C520B36FF399795D8B847ADF21E2559CDB3EC0CDE8E8AF322B1397B9531598C5CA1215385F6CE8113248
Key-Arg   : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
 - 33 fa b8 44 6b 0f fe 61-e5 14 06 66 19 9d 0e 73   3..Dk..a...f...s
0010 - 8f 06 54 21 20 97 7d ac-2c c4 12 91 c8 c0 c7 7f   ..T! .}.,...
0020 - 09 8a c8 13 0a 58 fc 16-e2 f3 96 67 c6 d6 d5 58   .X.g...X
0030 - ab 60 47 fc 66 22 17 8b-04 73 fd 2d a5 62 c4 35   .`G.f"...s.-.b.5
0040 - e8 dc 3a a9 e6 37 ba 2a-ea 05 0d ea fb 5a 01 80   ..:..7.*.Z..
0050 - 88 9e 6a 5d 7b ae 21 8f-89 32 af ae 0c 52 20 27   ..j]{.!..2...R '
0060 - 2f 1b 8e ae 18 82 54 c0-ee e4 b9 bb 1e 71 be db   /.T..q..
0070 - c3 0e 36 9f 0b ce a4 2e-be dc 1d 3f 10 01 08 71   ..6?...q
0080 - ae 74 b1 d4 1f ce 46 a3-94 54 93 ad 67 4a 72 15   .tF..T..gJr.
0090 - 93 5a 46 0c 84 35 f2 b6-7e 2d 7a 07 b5 7a ca 47   .ZF..5..~-z..z.G
00a0 - 

Re: SVN does not trust cert

[Daniel Sahlberg]

Den mån 25 mars 2024 kl 16:34 skrev Stanley Gilliam <
stanley.x.gill...@gsk.com>:

> Hello,
>
>
>
> So we use appview to update our certificates and our cert team confirmed
> that the cert was updated correctly. Is there another way to possibly
> verify this. There may also be something to the second option, I am on a
> linux RH OS. Is there a way someone could jump on a short call with us?
>

What if you run the same command as Jeffrey already tries, ie:

$ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com

(I had to Ctrl-D out of the above command). I'm not familiar with openssl
debugging but there seems to be a lot of useful information on the
certificate chain. Verify that all the intermediary certificates are
available and that the root certificate is trusted by your client.

Kind regards,
Daniel





>
>
> Stanley Gilliam
>
> System Administrator
>
> GSK
>
> 14200 Shady Grove Rd
>
> Rockville, MD 20850
>
> 678-548-7768
>
>
>
> *From:* Daniel Sahlberg 
> *Sent:* Monday, March 25, 2024 11:17 AM
> *To:* noloa...@gmail.com
> *Cc:* Stanley Gilliam ;
> users@subversion.apache.org
> *Subject:* Re: SVN does not trust cert
>
>
>
> Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton  com>: On Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  subversion. apache. org> wrote: > > I am a system admin for
> GlaxoSmithKline. We are currently
>
> Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton :
>
> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  wrote:
> >
> > I am a system admin for GlaxoSmithKline. We are currently having issues
> getting our svn instance to authenticate. This all happened after the cert
> was updated. We are currently getting the message :
> >
> > svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server
> certificate verification failed: issuer is not trusted (
> https://hpc.gsk.com)
> >
> > The cert was updated correctly we believe because the website works.
> >
> > is there anybody that may be able to help?
>
> DNS seems to be a problem:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
> 40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
> lib:../crypto/bio/bio_addr.c:738:Name or service not known
> connect:errno=22
>
> And:
>
> $ nslookup hpc.gsk.com
> Server: 127.0.0.53
> Address:127.0.0.53#53
>
> ** server can't find hpc.gsk.com: NXDOMAIN
>
> You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.
>
>
>
> It might be that the hpc.gsk.com domain is only available on an internal
> network (ie, on an internal DNS server). If there was a missing DNS entry
> you should get an error message similar to this:
>
>
>
> $ svn ls https://hpc.gsk.com
>
> svn: E170013: Unable to connect to a repository at URL '
> https://hpc.gsk.com'
>
> svn: E670002: Name or service not known
>
> $
>
>
>
> (The missing DNS entry makes it more difficult for someone outside of the
> company to help in debugging of course!).
>
>
>
> "issuer is not trusted" sounds to me like it is a self-signed certificate
> or that the certificate is signed by a root that isn't trusted by the
> client. Can you verify that the client really trust the issuer of the
> certificate?
>
>
>
> Another potential explanation (although not supported by the available
> evidence) is that there is a mismatch between the cipher of the new
> certificate compared to what OpenSSL on the client is supporting.
>
>
>
> Which platform are you on and what are the versions of Subversion and the
> linked OpenSSL library?
>
>
>
> Kind regards,
>
> Daniel
>
>
>
> *GSK monitors email communications sent to and from GSK in order to
> protect GSK, our employees, customers, suppliers and business partners,
> from cyber threats and loss of GSK Information. GSK monitoring is conducted
> with appropriate confidentiality controls and in accordance with local laws
> and after appropriate consultation.*
>

RE: SVN does not trust cert

[Stanley Gilliam via users]

Hello,

So we use appview to update our certificates and our cert team confirmed that 
the cert was updated correctly. Is there another way to possibly verify this. 
There may also be something to the second option, I am on a linux RH OS. Is 
there a way someone could jump on a short call with us?

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768

From: Daniel Sahlberg 
Sent: Monday, March 25, 2024 11:17 AM
To: noloa...@gmail.com
Cc: Stanley Gilliam ; users@subversion.apache.org
Subject: Re: SVN does not trust cert

Den mån 25 mars 2024 kl 15: 19 skrev Jeffrey Walton : On 
Mon, Mar 25, 2024 at 9: 54 AM Stanley Gilliam via users  wrote: > > I am a system admin for GlaxoSmithKline. We are 
currently

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton 
mailto:noloa...@gmail.com>>:
On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
mailto:users@subversion.apache.org>> wrote:
>
> I am a system admin for GlaxoSmithKline. We are currently having issues 
> getting our svn instance to authenticate. This all happened after the cert 
> was updated. We are currently getting the message :
>
> svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server 
> certificate verification failed: issuer is not trusted (https://hpc.gsk.com)
>
> The cert was updated correctly we believe because the website works.
>
> is there anybody that may be able to help?

DNS seems to be a problem:

$ openssl s_client -connect hpc.gsk.com:443 -servername 
hpc.gsk.com
40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
lib:../crypto/bio/bio_addr.c:738:Name or service not known
connect:errno=22

And:

$ nslookup hpc.gsk.com
Server: 127.0.0.53
Address:127.0.0.53#53

** server can't find hpc.gsk.com: NXDOMAIN

You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.

It might be that the hpc.gsk.com domain is only available 
on an internal network (ie, on an internal DNS server). If there was a missing 
DNS entry you should get an error message similar to this:

$ svn ls https://hpc.gsk.com
svn: E170013: Unable to connect to a repository at URL 'https://hpc.gsk.com'
svn: E670002: Name or service not known
$

(The missing DNS entry makes it more difficult for someone outside of the 
company to help in debugging of course!).

"issuer is not trusted" sounds to me like it is a self-signed certificate or 
that the certificate is signed by a root that isn't trusted by the client. Can 
you verify that the client really trust the issuer of the certificate?

Another potential explanation (although not supported by the available 
evidence) is that there is a mismatch between the cipher of the new certificate 
compared to what OpenSSL on the client is supporting.

Which platform are you on and what are the versions of Subversion and the 
linked OpenSSL library?

Kind regards,
Daniel


GSK monitors email communications sent to and from GSK in order to protect GSK, 
our employees, customers, suppliers and business partners, from cyber threats 
and loss of GSK Information. GSK monitoring is conducted with appropriate 
confidentiality controls and in accordance with local laws and after 
appropriate consultation.

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 11:34 AM Stanley Gilliam
 wrote:
>
> So we use appview to update our certificates and our cert team confirmed that 
> the cert was updated correctly. Is there another way to possibly verify this. 
> There may also be something to the second option, I am on a linux RH OS. Is 
> there a way someone could jump on a short call with us?

We don't know what the certificate chain or the end entity certificate
looks like. You have not described it, and you have not posted the
output of the openssl command. For me, it is not clear what has been
done to the server (replaced an end entity certificate?) and what has
been done to a typical client (nothing because the PKI has not
changed?)

At this point, all folks can do is guess.

Jeff

Re: SVN does not trust cert

[Daniel Sahlberg]

Den mån 25 mars 2024 kl 15:19 skrev Jeffrey Walton :

> On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
>  wrote:
> >
> > I am a system admin for GlaxoSmithKline. We are currently having issues
> getting our svn instance to authenticate. This all happened after the cert
> was updated. We are currently getting the message :
> >
> > svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server
> certificate verification failed: issuer is not trusted (
> https://hpc.gsk.com)
> >
> > The cert was updated correctly we believe because the website works.
> >
> > is there anybody that may be able to help?
>
> DNS seems to be a problem:
>
> $ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
> 40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
> lib:../crypto/bio/bio_addr.c:738:Name or service not known
> connect:errno=22
>
> And:
>
> $ nslookup hpc.gsk.com
> Server: 127.0.0.53
> Address:127.0.0.53#53
>
> ** server can't find hpc.gsk.com: NXDOMAIN
>
> You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.
>

It might be that the hpc.gsk.com domain is only available on an internal
network (ie, on an internal DNS server). If there was a missing DNS entry
you should get an error message similar to this:

$ svn ls https://hpc.gsk.com
svn: E170013: Unable to connect to a repository at URL 'https://hpc.gsk.com'
svn: E670002: Name or service not known
$

(The missing DNS entry makes it more difficult for someone outside of the
company to help in debugging of course!).

"issuer is not trusted" sounds to me like it is a self-signed certificate
or that the certificate is signed by a root that isn't trusted by the
client. Can you verify that the client really trust the issuer of the
certificate?

Another potential explanation (although not supported by the available
evidence) is that there is a mismatch between the cipher of the new
certificate compared to what OpenSSL on the client is supporting.

Which platform are you on and what are the versions of Subversion and the
linked OpenSSL library?

Kind regards,
Daniel

Re: SVN does not trust cert

[Jeffrey Walton]

On Mon, Mar 25, 2024 at 9:54 AM Stanley Gilliam via users
 wrote:
>
> I am a system admin for GlaxoSmithKline. We are currently having issues 
> getting our svn instance to authenticate. This all happened after the cert 
> was updated. We are currently getting the message :
>
> svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server 
> certificate verification failed: issuer is not trusted (https://hpc.gsk.com)
>
> The cert was updated correctly we believe because the website works.
>
> is there anybody that may be able to help?

DNS seems to be a problem:

$ openssl s_client -connect hpc.gsk.com:443 -servername hpc.gsk.com
40D7F6E4F171:error:10080002:BIO routines:BIO_lookup_ex:system
lib:../crypto/bio/bio_addr.c:738:Name or service not known
connect:errno=22

And:

$ nslookup hpc.gsk.com
Server: 127.0.0.53
Address:127.0.0.53#53

** server can't find hpc.gsk.com: NXDOMAIN

You should add a DNS entry for the host 'hpc'. Then, rerun the experiment.

Jeff

SVN does not trust cert

[Stanley Gilliam via users]

Hi,

I am a system admin for GlaxoSmithKline. We are currently having issues getting 
our svn instance to authenticate. This all happened after the cert was updated. 
We are currently getting the message :

svn: E175002: OPTIONS of 'https://hpc.gsk.com/xxx/xxx/etc': Server certificate 
verification failed: issuer is not trusted (https://hpc.gsk.com)

The cert was updated correctly we believe because the website works.

is there anybody that may be able to help?

Stanley Gilliam
System Administrator
GSK
14200 Shady Grove Rd
Rockville, MD 20850
678-548-7768


GSK monitors email communications sent to and from GSK in order to protect GSK, 
our employees, customers, suppliers and business partners, from cyber threats 
and loss of GSK Information. GSK monitoring is conducted with appropriate 
confidentiality controls and in accordance with local laws and after 
appropriate consultation.

Re: E200004 error during commit

[Robin]

I believe this unfortunately means your repository is corrupt. If you 
have a backup of the repository, the easiest way is probably to 
restore the backup.


If you don't have a backup and have to try to manually restore the 
repository, Daniel Shahaf goes into quite a bit of detail in these 
previous threads on the mailing list:


https://lists.apache.org/thread/8sokdqly67db11g6vs5v547xwz1hrp74
https://lists.apache.org/thread/0y7kpppv3f0ms301m13pw0qybr47wjb4

Maybe these can help you to figure out the correct value of the L2P 
offset?


Unfortunately, I don't have a backup. The current revision is 1203, so 
this means the corruption is way back in r319?


After reading the threads, I don't quite understand how to fix L2P. The 
problem is now sometimes I'm unable to commit.


Robin


On 3/16/2024 8:49 PM, Daniel Sahlberg wrote:

Den tors 14 mars 2024 kl 05:22 skrev Robin :

Hi,

when committing to folder, I get a

Commit failed (details follow):
Invalid L2P offset in r320 footer
Could not convert '�x�ț���C � Y+�
     ��ׁ%�?�l��\wH ��O3D�� b�4 �z ͦcr42 �Z2� �9g�,h$c
     �yM .��"�?z��X: ~j� m�S  �' into a number

svnadmin verify gives


* Verifying metadata at revision 0 ...
* Error verifying repository metadata.
svnadmin: E24: Invalid L2P offset in r319 footer
svnadmin: E24: Could not convert

'L��>q��y���B�|Q�`E⌂♠A�r�Y�X1V}���g6.�☼�ݥ�♂�M�,♫�]I̠◄�8►�ِ���Ya↕4♠�%��e�'��XRf1�◄��OY�D`F�',►VRG�޾�]u'

into a number


SVN 1.14.2

Robin

Re: E200004 error during commit

[Daniel Sahlberg]

Den tors 14 mars 2024 kl 05:22 skrev Robin :

> Hi,
>
> when committing to folder, I get a
>
> Commit failed (details follow):
> Invalid L2P offset in r320 footer
> Could not convert '�x�ț���C � Y+�
>  ��ׁ%�?�l��\wH ��O3D�� b�4 �z ͦcr42 �Z2� �9g�,h$c
>  �yM .��"�?z��X: ~j� m�S  �' into a number
>
> svnadmin verify gives
>
>
> * Verifying metadata at revision 0 ...
> * Error verifying repository metadata.
> svnadmin: E24: Invalid L2P offset in r319 footer
> svnadmin: E24: Could not convert
> 'L��>q��y���B�|Q�`E⌂♠A�r�Y�X1V}���g6.�☼�ݥ�♂�M�,♫�]I̠◄�8►�ِ���Ya↕4♠�%��e�'��XRf1�◄��OY�D`F�',►VRG�޾�]u'
>
> into a number
>
>
> SVN 1.14.2
>
> Robin
>
>
Hi,

I believe this unfortunately means your repository is corrupt. If you have
a backup of the repository, the easiest way is probably to restore the
backup.

If you don't have a backup and have to try to manually restore the
repository, Daniel Shahaf goes into quite a bit of detail in these previous
threads on the mailing list:

https://lists.apache.org/thread/8sokdqly67db11g6vs5v547xwz1hrp74
https://lists.apache.org/thread/0y7kpppv3f0ms301m13pw0qybr47wjb4

Maybe these can help you to figure out the correct value of the L2P offset?

Kind regards,
Daniel Sahlberg

E200004 error during commit

[Robin]

Hi,

when committing to folder, I get a

Commit failed (details follow):
Invalid L2P offset in r320 footer
Could not convert '�x�ț���C�Y+�
    ��ׁ%�?�l��\wH��O3D��b�4�zͦcr42�Z2��9g�,h$c
    �yM.��"�?z��X:~j�m�S�' into a number

svnadmin verify gives


* Verifying metadata at revision 0 ...
* Error verifying repository metadata.
svnadmin: E24: Invalid L2P offset in r319 footer
svnadmin: E24: Could not convert 
'L��>q��y���B�|Q�`E⌂♠A�r�Y�X1V}���g6.�☼�ݥ�♂�M�,♫�]I̠◄�8►�ِ���Ya↕4♠�%��e�'��XRf1�◄��OY�D`F�',►VRG�޾�]u' 
into a number



SVN 1.14.2

Robin

Re: SVN log --xml version omits line count

[sebb]

On Tue, 5 Mar 2024 at 19:01, Daniel Sahlberg
 wrote:
>
> Den tis 5 mars 2024 kl 18:09 skrev sebb :
>>
>> I would expect svn log --xml to include all the same info as the
>> non-xml version, but that is not the case. The number of lines changed
>> is not visible in the xml version.
>
>
> The figure is the number of lines in the log message, not the number of 
> changed lines in the commit.

Duh!

That makes sense now.

>>
>>
>> Is that intentional?
>>
>> If so, why?
>
>
> One could imagine that a parser of the text output would like to know the 
> number of lines to read before expecting the next log message. (Looking for 
> "" 
> could break down if someone has that exact string in a log message).

Indeed, that had occurred to me as a potential parsing issue.

> With XML, there is no need to know how long the log message is; a 
> well-behaved parser should be able to find out.
>
> Kind regards,
> Daniel

Thanks for the quick response.

>>
>> Sebb
>> Sample outputs below
>> -
>>
>> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE -r1914220
>> 
>> r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov
>> 2023) | 6 lines
>>
>> Update copyright year to 2023.
>>
>> * NOTICE,
>> * subversion/libsvn_subr/version.c (svn_version_extended):
>> Bump copyright year to 2023.
>>
>> 
>>
>> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
>> -r1914220 --xml
>> 
>> 
>> >revision="1914220">
>> hartmannathan
>> 2023-11-30T04:47:33.883414Z
>> Update copyright year to 2023.
>>
>> * NOTICE,
>> * subversion/libsvn_subr/version.c (svn_version_extended):
>> Bump copyright year to 2023.
>> 
>> 
>> 

Re: SVN log --xml version omits line count

[Daniel Sahlberg]

Den tis 5 mars 2024 kl 18:09 skrev sebb :

> I would expect svn log --xml to include all the same info as the
> non-xml version, but that is not the case. The number of lines changed
> is not visible in the xml version.


The figure is the number of lines in the log message, not the number of
changed lines in the commit.


>
> Is that intentional?

If so, why?
>

One could imagine that a parser of the text output would like to know the
number of lines to read before expecting the next log message. (Looking for
""
could break down if someone has that exact string in a log message).

With XML, there is no need to know how long the log message is; a
well-behaved parser should be able to find out.

Kind regards,
Daniel


> Sebb
> Sample outputs below
> -
>
> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
> -r1914220
> 
> r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov
> 2023) | 6 lines
>
> Update copyright year to 2023.
>
> * NOTICE,
> * subversion/libsvn_subr/version.c (svn_version_extended):
> Bump copyright year to 2023.
>
> 
>
> $ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
> -r1914220
>  --xml
> 
> 
> revision="1914220">
> hartmannathan
> 2023-11-30T04:47:33.883414Z
> Update copyright year to 2023.
>
> * NOTICE,
> * subversion/libsvn_subr/version.c (svn_version_extended):
> Bump copyright year to 2023.
> 
> 
> 
>

SVN log --xml version omits line count

[sebb]

I would expect svn log --xml to include all the same info as the
non-xml version, but that is not the case. The number of lines changed
is not visible in the xml version.

Is that intentional?
If so, why?

Sebb
Sample outputs below
-

$ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE -r1914220

r1914220 | hartmannathan | 2023-11-30 04:47:33 + (Thu, 30 Nov
2023) | 6 lines

Update copyright year to 2023.

* NOTICE,
* subversion/libsvn_subr/version.c (svn_version_extended):
Bump copyright year to 2023.



$ svn log https://svn.apache.org/repos/asf/subversion/trunk/NOTICE
-r1914220 --xml



hartmannathan
2023-11-30T04:47:33.883414Z
Update copyright year to 2023.

* NOTICE,
* subversion/libsvn_subr/version.c (svn_version_extended):
Bump copyright year to 2023.

Community Over Code Asia 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code Asia 2024 are now
open!

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this year's applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, May 10th, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you to
apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

Re: [EXTERNAL] Re: Moved file resolution fails

[Johan Corveleyn]

On Thu, Feb 15, 2024 at 7:32 PM Sands, Daniel N. via users
 wrote:
...
> On a further note, my real repo has 260 moves due to source tree
> restructuring.  There were 290 deletions.  The current move detection
> algorithm is an O(n^2) search to find all moves, where it ends up
> querying the SVN server 260*290 times for merge info, per file
> conflict.  Perhaps it would be a good cost savings to cache the merge
> info for each file during the search, so that there are O(n) trips to
> the server and everything else is resolved locally?

I don't know the tree conflict resolver code very well, so I'm not
sure if it works that way, with O(n^2) calls. But it's definitely a
good suggestion / idea to look closer into those calls and trying some
strategies to optimize things.

Would you have time / be able to dig deeper and try some things in the
code yourself, maybe come up with a patch [1], or a proposal / idea in
pseudo-code (best sent to d...@subversion.apache.org for discussion)?
These days the SVN community is completely volunteer-driven, so any
help is more than welcome :-).

[1] https://subversion.apache.org/docs/community-guide/general.html#patches

-- 
Johan

Re: Moved file resolution fails

[Johan Corveleyn]

On Wed, Feb 14, 2024 at 11:00 PM Sands, Daniel N. via users
 wrote:
>
> >
> Okay, I finally figured out how to trip up SVN:
>
>
>
>
> > > I built my own experiment which I'll try to reconstruct here:
> > > mkdir test
> > > mkdir test/foo
> > > mkdir test/foo/bar
> > > mkdir test/baz
> > > echo "a" > test/foo/bar/example.c
> > > svn import test svn+ssh://theserver/var/svn/playground/test
> > > rm -rf test
> > > svn co svn+ssh://theserver/var/svn/playground/test
> > > cd test
>
> Now I did something that SVN apparently doesn't like:
>
> svn mv foo/bar/example.c baz
> svn cp . ^/playground/test2

Hm, that's quite an atypical set of operations. The first command
makes a local move in the 'test' working copy (without committing that
move), and then creates a branch-from-WC with a local modification in
it. Creating a branch from a working copy is a bit special, precisely
because it may carry along local mods that are not committed to the
branch source. This is translated by SVN into copy of the branch
source, with the local modifications injected "on top". If you 'svn
log -v' the revision that created that branch I think you'll see
something like this:

A + /playground/test2 (from /playground/test:XXX)
D/playground/test2/foo/bar/example.c
A + /playground/test2/foo/baz/example.c (from
/playground/test/foo/bar/example.c:XXX)

As you can see, the Deleted file is different from the "copyfrom" of
the Added file (which is copied from the original pre-branch
location). So the simple logic in the tree conflict resolver cannot
detect that D-A pair as a move (it is not smart enough to see that you
created test2 from test in the exact same revision). In theory, this
should be a supportable scenario, but it'll take some special handling
I think.

When I create branches, I usually do so purely in the repository, by
copying URL's (either from TortoiseSVN's repo browser, or by 'svn cp
URL1 URL2' -- keep in mind that the caret for SVN is a shortcut for
the repo-root-URL). That way the branch is a "clean" copy from
something else in the repository. I prefer to keep other changes
separate from the branch-creation, so either I commit them before or
after creating the branch.

The only exception I make to this is when creating tags for release,
where I commit a "version-number" change in some file together with
creating the tag. That's how the Subversion project creates its
release tags too, see for example
http://svn.apache.org/viewvc?view=revision=1914487

-- 
Johan

Re: [EXTERNAL] Re: Moved file resolution fails

[Sands, Daniel N. via users]

On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-Garcia wrote:
> [You don't often get email from nka...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
>  wrote:
> 
> > So lesson learned:  Always make a pristine copy of the trunk before
> > making ANY changes, so that there is a revision to fall back on
> > where
> > the two branches exactly match.
> 
> That's what tags are for!

I'd heard of tagging but wasn't sure how to do it since I'm not
responsible for the releases... but it looks like you tag by using the
copy command.  Even worse, the text under "complex tagging" shows
copying your working directory to a new repo, which is what breaks the
file move/rename detection.

On a further note, my real repo has 260 moves due to source tree
restructuring.  There were 290 deletions.  The current move detection
algorithm is an O(n^2) search to find all moves, where it ends up
querying the SVN server 260*290 times for merge info, per file
conflict.  Perhaps it would be a good cost savings to cache the merge
info for each file during the search, so that there are O(n) trips to
the server and everything else is resolved locally?

Re: Moved file resolution fails

[Nico Kadel-Garcia]

On Wed, Feb 14, 2024 at 4:59 PM Sands, Daniel N. via users
 wrote:

> So lesson learned:  Always make a pristine copy of the trunk before
> making ANY changes, so that there is a revision to fall back on where
> the two branches exactly match.

That's what tags are for!

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> 
Okay, I finally figured out how to trip up SVN:




> > I built my own experiment which I'll try to reconstruct here:
> > mkdir test
> > mkdir test/foo
> > mkdir test/foo/bar
> > mkdir test/baz
> > echo "a" > test/foo/bar/example.c
> > svn import test svn+ssh://theserver/var/svn/playground/test
> > rm -rf test
> > svn co svn+ssh://theserver/var/svn/playground/test
> > cd test

Now I did something that SVN apparently doesn't like:

svn mv foo/bar/example.c baz
svn cp . ^/playground/test2

Problem:  This prevents SVN's mergeinfo search since on merge it looks
for the info on foo/bar/example.c at its previous revision in test2. 
The test2 repository itself does not exist in the previous revision,
let alone any file in it.  So, for example, we continue:


> > svn revert -R .
> > echo "b" > foo/bar/example.c
> > svn commit
> > cd ..
svn co svn+ssh://theserver/var/svn/playground/test2
cd test2
> > svn merge ^/playground/test 


And now here come the unresolvable conflicts!

So lesson learned:  Always make a pristine copy of the trunk before
making ANY changes, so that there is a revision to fall back on where
the two branches exactly match.

Re: Moved file resolution fails

[Sands, Daniel N. via users]

On Tue, 2024-02-13 at 16:50 -0700, Daniel Sands wrote:
> > Sorry for the late response, but I lack the time to dig deeper. It
> > should work as in the example (test) that Stanimir Stamenkov posted
> > earlier in this thread.
> > 
> I don't fully follow that Derby example, but it does not look like
> the
> same thing.
> 
> I built my own experiment which I'll try to reconstruct here:
> 
> mkdir test
> mkdir test/foo
> mkdir test/foo/bar
> mkdir test/baz
> echo "a" > test/foo/bar/example.c
> svn import test svn+ssh://theserver/var/svn/playground/test
> rm -rf test
> svn co svn+ssh://theserver/var/svn/playground/test
> cd test
> svn cp . ^/playground/test2
> cd ..
> svn co svn+ssh://theserver/var/svn/playground/test2
> cd test
> echo "b" > foo/bar/example.c
> svn commit
> cd ../test2
> svn merge ^/playground/test .
> 
> 
Further investigation from debugging the svn client 1.14:  In the above
test branch, the conflict resolution goes through the function
find_revision_for_suspected_deletion and returns the revision where it
happened.  But in my problem branch, this function cannot find the
revision where the file was deleted.  This makes no sense to me, as it
was in the previous checkin.

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> Sorry for the late response, but I lack the time to dig deeper. It
> should work as in the example (test) that Stanimir Stamenkov posted
> earlier in this thread.
>
> Is your case the same as in the DERBY issue that Stanimir referenced
> [1]? Maybe you can narrow it down to a test with a repository from
> scratch, or narrow down to a specific step that might have confused
> the tree conflict resolver?
>
> Perhaps someone else on this list has some more ideas / can zoom in
> on
> the case in [1]?
>
> [1]
> https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731
>

I don't fully follow that Derby example, but it does not look like the
same thing.

I built my own experiment which I'll try to reconstruct here:

mkdir test
mkdir test/foo
mkdir test/foo/bar
mkdir test/baz
echo "a" > test/foo/bar/example.c
svn import test svn+ssh://theserver/var/svn/playground/test
rm -rf test
svn co svn+ssh://theserver/var/svn/playground/test
cd test
svn cp . ^/playground/test2
cd ..
svn co svn+ssh://theserver/var/svn/playground/test2
cd test
echo "b" > foo/bar/example.c
svn commit
cd ../test2
svn merge ^/playground/test .

This causes some interesting back-and-forth as it first records the
tree conflict on foo/bar, then starts checking for tree conflicts.
Looks like 1.14 did at least improve on the results though.

1.10 searched back through the revisions and finally gave up with:
Tree conflict on 'foo/bar':
Changes destined for a directory arrived via the following revisions
during merge of
'^/playground/test/foo/bar:34563-34565':
 r34562 by dnsands, r34565 by dnsands
No such file or directory was found in the merge target working copy.
The directory was moved to '^/playground/test2/baz/bar' in r34564 by
dnsands.

Subversion is not smart enough to resolve this tree conflict
automatically!
See 'svn help resolve' for more information.

1.14 was able to fully resolve the conflict by itself:
Changes destined for a directory arrived via the following revisions
during merge of
'^/playground/test/foo/bar:34563-34565':
 r34562 by dnsands, r34565 by dnsands
No such file or directory was found in the merge target working copy.
The directory was moved to '^/playground/test2/baz/bar' in r34564 by
dnsands.
Applying recommended resolution 'Apply to move destination':
--- Merging differences between repository URLs into 'baz/bar':
Ubaz/bar/example.c
Tree conflict at 'foo/bar' marked as resolved.
Summary of conflicts:
  Tree conflicts: 0 remaining (and 1 already resolved)

That's nice for this example at least, but it would seem that my actual
case was a bit more complex, as even 1.14 was unable to find the
original file.  I'll have to see if I can reproduce that in a simpler
case.  What I know is that it was unable to find a common ancestor
where the incoming merge destination existed.

Re: Moved file resolution fails

[Johan Corveleyn]

On Mon, Feb 5, 2024 at 8:57 PM Sands, Daniel N. via users
 wrote:
> > Oh yes, a lot has changed since 1.8 (which is EOL for a long time
> > already). Actually, the major improvement came client-side in version
> > 1.10, with the interactive tree conflict resolver [1]. This uses a
> > lot
> > of information from both working copy and repository to figure out
> > what the sensible options are in case of a tree conflict, and
> > attempts
> > to resolve some of those automatically. You should upgrade your
> > clients to _at least_ 1.10 to have a reasonable experience with tree
> > conflict situations. After 1.10 lots of bugfixes and improvements
> > have
> > been made to the tree conflict resolver, so I would recommend to go
> > for 1.14 (which is actually the only supported version ATM [2]).
>
> Yeah I'm using RHEL8 which currently supports 1.10.  I also compiled
> the latest version of 1.14 to see if it had any improvement.
> Unfortunately they all fail the same way in attempting to resolve file
> moves.

Sorry for the late response, but I lack the time to dig deeper. It
should work as in the example (test) that Stanimir Stamenkov posted
earlier in this thread.

Is your case the same as in the DERBY issue that Stanimir referenced
[1]? Maybe you can narrow it down to a test with a repository from
scratch, or narrow down to a specific step that might have confused
the tree conflict resolver?

Perhaps someone else on this list has some more ideas / can zoom in on
the case in [1]?

[1] 
https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731

-- 
Johan

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> 
> Oh yes, a lot has changed since 1.8 (which is EOL for a long time
> already). Actually, the major improvement came client-side in version
> 1.10, with the interactive tree conflict resolver [1]. This uses a
> lot
> of information from both working copy and repository to figure out
> what the sensible options are in case of a tree conflict, and
> attempts
> to resolve some of those automatically. You should upgrade your
> clients to _at least_ 1.10 to have a reasonable experience with tree
> conflict situations. After 1.10 lots of bugfixes and improvements
> have
> been made to the tree conflict resolver, so I would recommend to go
> for 1.14 (which is actually the only supported version ATM [2]).

Yeah I'm using RHEL8 which currently supports 1.10.  I also compiled
the latest version of 1.14 to see if it had any improvement. 
Unfortunately they all fail the same way in attempting to resolve file
moves.

Community over Code EU 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code EU 2024 are now
open!

We will be supporting Community over Code EU, Bratislava, Slovakia,
June 3th - 5th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this years applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, March 1st, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Bratislava, Slovakia in June,
2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

[no subject]

[Gavin McDonald]

Hello to all users, contributors and Committers!

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code EU 2024 are now
open!

We will be supporting Community over Code EU, Bratislava, Slovakia,
June 3th - 5th, 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this years applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Friday, March 1st, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Bratislava, Slovakia in June,
2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

Re: Moved file resolution fails

[Stanimir Stamenkov via users]

Fri, 2 Feb 2024, /Johan Corveleyn/:

On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users wrote:

   * Tree conflicts flagged by svn merge cannot be automatically resolved 
yet. This will be addressed in a future release.


If I understand correctly, not much has changed related to merging 
with/into moved files.


Oh yes, a lot has changed since 1.8 (which is EOL for a long time 
already). Actually, the major improvement came client-side in version 
1.10, with the interactive tree conflict resolver [1]...

[...]
- Despite this, the tree conflict resolver in 1.10+ is in most cases 
able to match deletes and adds-with-copyfrom to deduce they are 
probably a move, and uses this kind of information to make a good 
guess about what needs to go where. It seems to work out fine in 
practice in most cases.


[1] https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver


Thank you for the references and additional info.  I have to admit I'm 
using Subversion just when absolutely necessary, since quite some time 
now.  And then I'm not the OP with the problem.  In this regard I 
haven't tested extensively whether and how svn merge with moved files 
may have improved, but here's an example from ~1.5 year ago using 
Subversion 1.14:


https://issues.apache.org/jira/browse/DERBY-7144?focusedCommentId=17582731=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17582731

(there's a "svn-merge.log" link to an attachment with the full session)

The example performs a cherry-pick (back-port) merge:

svn merge -c  ^//branches/

It doesn't seem to notice the source has once been renamed from the 
target, and doesn't perform automatic merge.  Maybe this one is specific 
to cherry-pick merges?


I've now tried simplified scenario described by the OP – it does appear 
to automatically merge updates to a moved file (this is a Windows 
Command Prompt):


> svn info
Path: .
Working Copy Root Path: C:\...\svnwork
URL: file:///C:/.../svnrepo/branches/feature-1
Relative URL: ^/branches/feature-1
Repository Root: file:///C:/.../svnrepo
Repository UUID: 9f01a344-90b5-c945-b13b-67a67f39ca98
Revision: 5
Node Kind: directory
Schedule: normal
Last Changed Author: stanio
Last Changed Rev: 4
Last Changed Date: 2024-02-02 15:32:09 +0200 (пет, 02 фев 2024)

> svn merge ^^/trunk
--- Merging r3 through r5 into '.':
   C foo
--- Recording mergeinfo for merge of r3 through r5 into '.':
 U   .
Summary of conflicts:
  Tree conflicts: 1
Searching tree conflict details for 'foo' in repository:
Checking r4... done
Tree conflict on 'foo':
Changes destined for a file arrived via the following revisions 
during merge of

'^/trunk/foo:3-5':
 r2 by stanio, r5 by stanio
No such file or directory was found in the merge target working copy.
The file was moved to '^/branches/feature-1/fou' in r4 by stanio.
Applying recommended resolution 'Apply to move destination':
Gfou
Tree conflict at 'foo' marked as resolved.
Summary of conflicts:
  Tree conflicts: 0 remaining (and 1 already resolved)

--
Stanimir

Re: Moved file resolution fails

[Johan Corveleyn]

On Fri, Feb 2, 2024 at 10:18 AM Stanimir Stamenkov via users
 wrote:
>
> Fri, 2 Feb 2024, /Sands, Daniel N./:
>
> >> As far as I'm aware this is all client-side behavior - nothing to do with 
> >> the server. Resource move/rename
> >> has always been recorded as a _Delete_ of the original path and a _Copy_ 
> >> (Add) from the previous path
> >> revision. It could be I'm missing something here, also.
> >
> > As of 1.8, it now knows if an add or delete was due to a move.  For 
> > example, on my RHEL8 system that has 1.10, a move will look like this in 
> > status:
> >
> > Dfoo/bar
> >> moved to baz/bar
> > Abaz/bar
> >> moved from foo/bar
> > [...]
>
> O.k.  I've now looked it up:
>
> "Working copy records moves as first-class operation"
> 
>
> Note the "working copy" (client-side):
>
> > Limitations:
> >
> >   * Moves are recorded as such only within the working copy. The link
> > between the copy and the delete is established only when a local move
> > operation is performed, and is lost upon commit. The committed revision
> > will show a copy and a delete, instead of a move.
>
> It is unclear to me whether the move info is retained in the source
> working copy after the commit, but is likely:
>
> > Known issues:
> >
> >   * Tree conflicts involving replacements are currently not detected
> > when updating a moved file or directory (see issue #4318).
> > 
>
> At the end:
>
> >   * Tree conflicts flagged by svn merge cannot be automatically resolved
> > yet. This will be addressed in a future release.
>
> If I understand correctly, not much has changed related to merging
> with/into moved files.

Oh yes, a lot has changed since 1.8 (which is EOL for a long time
already). Actually, the major improvement came client-side in version
1.10, with the interactive tree conflict resolver [1]. This uses a lot
of information from both working copy and repository to figure out
what the sensible options are in case of a tree conflict, and attempts
to resolve some of those automatically. You should upgrade your
clients to _at least_ 1.10 to have a reasonable experience with tree
conflict situations. After 1.10 lots of bugfixes and improvements have
been made to the tree conflict resolver, so I would recommend to go
for 1.14 (which is actually the only supported version ATM [2]).

You are of course free to discuss and seek help on this list for older
versions, but to me it makes no sense to complain about 1.8's
client-side tree conflict handling, when 1.10 and 1.14 perform so much
better in this regard.

Note also that:
- Even with 1.14, the information that you showed above about a move
in your working copy (with the "> moved to" and "> moved from"
details) is not transferred to the repository. After committing, the
repository (server) does not keep the same information (it does have
the "copyfrom" information in the Add, but that's it).
- So when looking at such a commit, or checking out and verifying
history, you cannot get the same ">moved to" and ">moved from"
information, because it is simply not there.
- Despite this, the tree conflict resolver in 1.10+ is in most cases
able to match deletes and adds-with-copyfrom to deduce they are
probably a move, and uses this kind of information to make a good
guess about what needs to go where. It seems to work out fine in
practice in most cases.

[1] https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver
[2] https://subversion.apache.org/docs/release-notes/#supported-versions

-- 
Johan

Re: Moved file resolution fails

[Stanimir Stamenkov via users]

Fri, 2 Feb 2024, /Sands, Daniel N./:


As far as I'm aware this is all client-side behavior - nothing to do with the 
server. Resource move/rename
has always been recorded as a _Delete_ of the original path and a _Copy_ (Add) 
from the previous path
revision. It could be I'm missing something here, also.


As of 1.8, it now knows if an add or delete was due to a move.  For example, on 
my RHEL8 system that has 1.10, a move will look like this in status:

Dfoo/bar
   > moved to baz/bar
Abaz/bar
   > moved from foo/bar
[...]


O.k.  I've now looked it up:

"Working copy records moves as first-class operation" 



Note the "working copy" (client-side):


Limitations:

  * Moves are recorded as such only within the working copy. The link 
between the copy and the delete is established only when a local move 
operation is performed, and is lost upon commit. The committed revision 
will show a copy and a delete, instead of a move.


It is unclear to me whether the move info is retained in the source 
working copy after the commit, but is likely:



Known issues:

  * Tree conflicts involving replacements are currently not detected 
when updating a moved file or directory (see issue #4318). 



At the end:

  * Tree conflicts flagged by svn merge cannot be automatically resolved 
yet. This will be addressed in a future release.


If I understand correctly, not much has changed related to merging 
with/into moved files.


--
Stanimir

Re: Moved file resolution fails

[Daniel Sahlberg]

fre 2 feb. 2024 kl. 06:52 skrev Sands, Daniel N. via users <
users@subversion.apache.org>:

> > As far as I'm aware this is all client-side behavior - nothing to do
> with the server. Resource move/rename
> > has always been recorded as a _Delete_ of the original path and a _Copy_
> (Add) from the previous path
> > revision. It could be I'm missing something here, also.
>
> As of 1.8, it now knows if an add or delete was due to a move.  For
> example, on my RHEL8 system that has 1.10, a move will look like this in
> status:
>
> Dfoo/bar
>   > moved to baz/bar
> Abaz/bar
>   > moved from foo/bar
>
> If I use this tree to update from even the 1.7 server, conflict resolution
> can find the change in the trunk to foo/bar/example.c and rewrite it to
> baz/bar/example.c.  The conflict resolution gives me the option to
> (u)pdate the destination of the change.
>
> However, if I check out my local branch from 1.7, the above 'moved'
> information is lost.


Which version are you using on the client side? Can you show the output of
svn —version?

Kind regards
Daniel Sahlberg

And in that case, conflict resolution fails.  There is a
> published paper that 1.8+ clients implement in resolving the new path in
> the absence of the 'moved' information.  It involves a heuristic where
> 1) the delete and the add must happen in the same checkin
> 2) the adds will be searched for some kind of common ancestry that can be
> used to match the add to the delete
>
> But whatever was implemented, the tree conflict search does not seem to
> find its common ancestry.  In addition, the example.c file modification
> record is lost, so after resolving the tree conflict there is still an
> incomplete merge even though it has the merge info recorded.
>
>

Re: Moved file resolution fails

[Sands, Daniel N. via users]

> As far as I'm aware this is all client-side behavior - nothing to do with the 
> server. Resource move/rename
> has always been recorded as a _Delete_ of the original path and a _Copy_ 
> (Add) from the previous path
> revision. It could be I'm missing something here, also.

As of 1.8, it now knows if an add or delete was due to a move.  For example, on 
my RHEL8 system that has 1.10, a move will look like this in status:

Dfoo/bar
  > moved to baz/bar
Abaz/bar
  > moved from foo/bar

If I use this tree to update from even the 1.7 server, conflict resolution can 
find the change in the trunk to foo/bar/example.c and rewrite it to
baz/bar/example.c.  The conflict resolution gives me the option to (u)pdate the 
destination of the change.

However, if I check out my local branch from 1.7, the above 'moved' information 
is lost.  And in that case, conflict resolution fails.  There is a
published paper that 1.8+ clients implement in resolving the new path in the 
absence of the 'moved' information.  It involves a heuristic where
1) the delete and the add must happen in the same checkin
2) the adds will be searched for some kind of common ancestry that can be used 
to match the add to the delete

But whatever was implemented, the tree conflict search does not seem to find 
its common ancestry.  In addition, the example.c file modification
record is lost, so after resolving the tree conflict there is still an 
incomplete merge even though it has the merge info recorded.

Re: Moved file resolution fails

[Stanimir Stamenkov via users]

Tue, 30 Jan 2024, /Sands, Daniel N./:

So far I have not found a use case where moved file resolution in 1.8+ 
works as advertised on 1.7 servers.  But more specifically, I have the 
following case:


The trunk has a directory,
/foo/bar

In my local branch, I have relocated bar to
/baz/bar

Meanwhile, in the trunk, file /foo/bar/example.c got updated.  My local 
branch has been checked out from the 1.7 server so it no longer knows 
specifically about file moves.  When I merge the latest changes from the 
trunk, it creates a tree conflict on /foo/bar. It has completely lost 
the notion that there is a file within /foo/bar that was edited.


As far as I'm aware this is all client-side behavior – nothing to do 
with the server.  Resource move/rename has always been recorded as a 
_Delete_ of the original path and a _Copy_ (Add) from the previous path 
revision.  It could be I'm missing something here, also.


 The 
conflict data only knows that /foo/bar doesn't exist anymore.  My only 
option for resolution is to accept working – the search for where 
/foo/bar went also fails. And now the incoming edit to example.c is 
completely lost, and I wouldn't even know it existed until I did an svn 
diff on each revision that got merged in.


If I remember correctly, this had only worked the way you expect – 
automatic content merge into the moved file, pre-Subversion 1.6 when 
tree conflicts have been introduced.  I have never been a fan of this 
change and the complication to the svn merge it adds.


The way you generally resolve tree conflicts is with an extra merge (but 
could also be a delete) command per file/tree conflict:


svg merge ^/foo/bar baz/bar

Then you mark the conflicting files (command per path) as resolved:

svn resolve baz/bar --accept working

and finally commit, if you're satisfied with the state.

--
Stanimir

Moved file resolution fails

[Sands, Daniel N. via users]

So far I have not found a use case where moved file resolution in 1.8+ works as 
advertised on 1.7 servers.  But more specifically, I have the following case:

The trunk has a directory,
/foo/bar

In my local branch, I have relocated bar to
/baz/bar

Meanwhile, in the trunk, file /foo/bar/example.c got updated.  My local branch 
has been checked out from the 1.7 server so it no longer knows specifically 
about file moves.  When I merge the latest changes from the trunk, it creates a 
tree conflict on /foo/bar.  It has completely lost the notion that there is a 
file within /foo/bar that was edited.  The conflict data only knows that 
/foo/bar doesn't exist anymore.  My only option for resolution is to accept 
working – the search for where /foo/bar went also fails.  And now the incoming 
edit to example.c is completely lost, and I wouldn't even know it existed until 
I did an svn diff on each revision that got merged in.

So in summary, conflict resolution cannot find the new location for the 'bar' 
directory, and it completely forgot that there was an incoming file edit within 
that directory.

Is this a missed case in the resolution heuristic?  Or is there something I 
missed?

Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

[Nathan Hartman]

On Sun, Jan 21, 2024 at 3:08 PM Nathan Hartman  wrote:
>
> On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
>  wrote:
> >
> > Hi,
> >
> > I'm trying to do a catchup merge between two branches (incidentally within 
> > the Subversion website tree) but I fail and I don't have enough 
> > understanding to know what is wrong.
> >
> > I have a working copy from https://svn.apache.org/repos/asf/subversion/site
> >
> > In $WC/staging/, I run:
> > [[[
> > $ svn merge ^/subversion/site/publish
> > svn: E195016: Reintegrate can only be used if revisions 1812681 through 
> > 1915353 were previously merged from 
> > https://svn.apache.org/repos/asf/subversion/site/staging to the reintegrate 
> > source, but this is not the case:
> >   subversion/site/publish
> > Missing ranges: 
> > /subversion/site/staging:1898163-1898164,1898168,1898183,1899002,1899183,1899186,1899621,1905961,1905965,1909457
> > ]]]
> >
> > The listed revisions all seem to be authored directly in staging and not 
> > yet merged to publish (related to the upcoming 1.15 release).
> >
> > What has gone wrong and what can we do to get back into a working state?
> >
> > Kind regards,
> > Daniel Sahlberg
>
>
> I also saw this when trying to reconcile staging and publish during
> the 1.14.3 release. I also thought this was an error, but after
> further examination I came to the conclusion that the message was
> correct. I can try to look into it later, but if you'd like to
> experiment with it first, I suggest looking at 'svn mergeinfo
> --show-revs eligible' of both branches and seeing what those unmerged
> revs are. I did this when I worked on the release and IIRC this is
> what I found:
>
> There are two different issues here (from what I remember):
>
> (1) Some time ago, there were some typos that I found in one of the
> release note pages and I subsequently grepped and fixed in multiple
> places on the staging branch. Those typos were also present in the
> 1.15 release notes, which are present in staging but not in publish.
> Unfortunately, when I fixed the typos (including in the 1.15 release
> notes), it didn't occur to me that they could not be merged cleanly to
> publish until publish also gained the 1.15 release notes.
>
> (2) svn-role updates the "upcoming changes in the next release"; since
> release(s) were made in the meantime, many of those "upcoming" changes
> are no longer listed -- svn-role deleted those texts. So, if you try
> cherrypicking those commits across the branches, I think you'll see
> text of old "upcoming changes" being added, and eventually being
> deleted again; the sum total is that no textual changes should remain
> once they're all merged, except text about the few backported changes
> that happened in the last 3 weeks.
>
> To get past the error, I think you can identify which revisions from
> that "missing ranges" list we don't actually need to merge from
> publish to staging (all svn-role "upcoming changes" up to the 1.14.3
> release) and do a --record-only merge; that will add those revs to
> staging's mergeinfo without changing any text. I think that should
> eliminate most of the complaint. If any revs remain, we can look into
> those and see what happened. Alternatively, if you don't feel
> comfortable with a --record-only merge, you could cherrypick them
> one-by-one and watch the text being added and subsequently removed.
>
> All that is from memory; hopefully I remember correctly. I'll try to
> look into it later...
>
> Hope this helps,
> Nathan


Okay here's what's going on:

You wanted to catch staging up to publish. Subversion wants the
reintegrate source (in this case, publish) to be strictly newer than
the destination (in this case, staging). This means we can do a bunch
of work on publish and merge it to staging; then we can do a bunch of
work on staging and merge it to publish. In effect, we alternately
make one branch newer and then reintegrate it to the other, and then
vice versa.

But, since we have some long-lived items in staging that have not yet
been merged to publish (namely, the not-yet-released 1.15 release
notes), publish is no longer strictly newer than staging. (Indeed, I
examined all the revisions it complains about and all of them happened
on the staging branch and involve the 1.15 release notes file.) This
is why we fail the checks that happen before the merge takes place and
we see the error. This is touched upon in the 1.18 release notes:

https://subversion.apache.org/docs/release-notes/1.8.html#auto-reintegrate

Note: In my previous message I mistakenly said that some svn-role
revisions were involved; I remembered incorrectly and in fact no such
revisions are mentioned in the error message.

What can we do?

We could choose to do nothing. On the publish branch,
'svn merge ^/subversion/site/staging' merges cleanly, so we can make
changes on staging (without first catching up to publish) and then
cherrypick those individual changes to publish. (By cherrypicking,
we'd avoid merging 

Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

[Nathan Hartman]

On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
 wrote:
>
> Hi,
>
> I'm trying to do a catchup merge between two branches (incidentally within 
> the Subversion website tree) but I fail and I don't have enough understanding 
> to know what is wrong.
>
> I have a working copy from https://svn.apache.org/repos/asf/subversion/site
>
> In $WC/staging/, I run:
> [[[
> $ svn merge ^/subversion/site/publish
> svn: E195016: Reintegrate can only be used if revisions 1812681 through 
> 1915353 were previously merged from 
> https://svn.apache.org/repos/asf/subversion/site/staging to the reintegrate 
> source, but this is not the case:
>   subversion/site/publish
> Missing ranges: 
> /subversion/site/staging:1898163-1898164,1898168,1898183,1899002,1899183,1899186,1899621,1905961,1905965,1909457
> ]]]
>
> The listed revisions all seem to be authored directly in staging and not yet 
> merged to publish (related to the upcoming 1.15 release).
>
> What has gone wrong and what can we do to get back into a working state?
>
> Kind regards,
> Daniel Sahlberg


I also saw this when trying to reconcile staging and publish during
the 1.14.3 release. I also thought this was an error, but after
further examination I came to the conclusion that the message was
correct. I can try to look into it later, but if you'd like to
experiment with it first, I suggest looking at 'svn mergeinfo
--show-revs eligible' of both branches and seeing what those unmerged
revs are. I did this when I worked on the release and IIRC this is
what I found:

There are two different issues here (from what I remember):

(1) Some time ago, there were some typos that I found in one of the
release note pages and I subsequently grepped and fixed in multiple
places on the staging branch. Those typos were also present in the
1.15 release notes, which are present in staging but not in publish.
Unfortunately, when I fixed the typos (including in the 1.15 release
notes), it didn't occur to me that they could not be merged cleanly to
publish until publish also gained the 1.15 release notes.

(2) svn-role updates the "upcoming changes in the next release"; since
release(s) were made in the meantime, many of those "upcoming" changes
are no longer listed -- svn-role deleted those texts. So, if you try
cherrypicking those commits across the branches, I think you'll see
text of old "upcoming changes" being added, and eventually being
deleted again; the sum total is that no textual changes should remain
once they're all merged, except text about the few backported changes
that happened in the last 3 weeks.

To get past the error, I think you can identify which revisions from
that "missing ranges" list we don't actually need to merge from
publish to staging (all svn-role "upcoming changes" up to the 1.14.3
release) and do a --record-only merge; that will add those revs to
staging's mergeinfo without changing any text. I think that should
eliminate most of the complaint. If any revs remain, we can look into
those and see what happened. Alternatively, if you don't feel
comfortable with a --record-only merge, you could cherrypick them
one-by-one and watch the text being added and subsequently removed.

All that is from memory; hopefully I remember correctly. I'll try to
look into it later...

Hope this helps,
Nathan

Re: Reintegrate can only be used if revisions XX through YY were previously merged ...

[Nico Kadel-Garcia]

On Sun, Jan 21, 2024 at 12:06 PM Daniel Sahlberg
 wrote:
>
> Hi,
>
> I'm trying to do a catchup merge between two branches (incidentally within 
> the Subversion website tree) but I fail and I don't have enough understanding 
> to know what is wrong.
>
> I have a working copy from https://svn.apache.org/repos/asf/subversion/site

Merging distinct branches is... one of the things that Subversion is
not best with. I'd suggest using "git-svn" locally to play with, to
see if you can resolve the differences by first merging from the
trunk, then pull in the branches, and *then* push to the upstream
branch.


> Daniel Sahlberg
>

Reintegrate can only be used if revisions XX through YY were previously merged ...

[Daniel Sahlberg]

Hi,

I'm trying to do a catchup merge between two branches (incidentally within
the Subversion website tree) but I fail and I don't have enough
understanding to know what is wrong.

I have a working copy from https://svn.apache.org/repos/asf/subversion/site

In $WC/staging/, I run:
[[[
$ svn merge ^/subversion/site/publish
svn: E195016: Reintegrate can only be used if revisions 1812681 through
1915353 were previously merged from
https://svn.apache.org/repos/asf/subversion/site/staging to the reintegrate
source, but this is not the case:
  subversion/site/publish
Missing ranges:
/subversion/site/staging:1898163-1898164,1898168,1898183,1899002,1899183,1899186,1899621,1905961,1905965,1909457
]]]

The listed revisions all seem to be authored directly in staging and not
yet merged to publish (related to the upcoming 1.15 release).

What has gone wrong and what can we do to get back into a working state?

Kind regards,
Daniel Sahlberg

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Fri, Jan 19, 2024 at 3:03 AM Olivier Sannier  wrote:

> Partial checkouts are somewhat possible with GIT but what is preventing me 
> from migrating our repository is the lack of svn:external mechanism.
> I don't want multirepos, and even then submodules are to be updated manually 
> everytime where svn:external are automatically up to date.
> And ideally, I would also need file externals support even if I could settle 
> for folder external if that's all there is.
> I looked a various solutions but none where as easy to use for developers 
> than externals when doing a "svn update" at the root of the checkout.
>
> That being said, I'd be quite happy to be proven wrong.

It's not a built-in. There are tools that have wrapped in
automatically updating subdirectories with git repos, such as
Terraform submodules. Terraform was written more to do one-time
checkouts in a CI/CD environment. It avoids the git submodule problem
of submodules being hooked to a particular commit, rather than an
easily updated branch by name, which requires a distinct update
procedure.  That is something that svn:externals handle a bit more
easily.

Re: Can't connect to github anymore

[Olivier Sannier]

Le 13/01/2024 à 22꞉11, Nico Kadel-Garcia a écrit :

On Sat, Jan 13, 2024 at 4:02 PM Johan Corveleyn  wrote:

On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:

hey there

suddenly i can't connect to github anymore (svn update or svn checkout)

i get the following error:

svn checkouthttps://github.com/roger21/fract.git
svn: E170013: Unable to connect to a repository at URL
'https://github.com/roger21/fract.git'
svn: E160013: '/roger21/fract.git' path not found

Apparently, GitHub has removed its support for the Subversion protocol:

https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/

--
Johan

The "git-svn" module has been my go-to tool for accessing legacy
Subversion repos for some time. There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.



Partial checkouts are somewhat possible with GIT but what is preventing 
me from migrating our repository is the lack of svn:external mechanism.
I don't want multirepos, and even then submodules are to be updated 
manually everytime where svn:external are automatically up to date.
And ideally, I would also need file externals support even if I could 
settle for folder external if that's all there is.
I looked a various solutions but none where as easy to use for 
developers than externals when doing a "svn update" at the root of the 
checkout.


That being said, I'd be quite happy to be proven wrong.

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Mon, Jan 15, 2024 at 8:05 AM Branko Čibej  wrote:
>
> On 14.01.2024 20:52, Nico Kadel-Garcia wrote:
>
> On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
> There are not many compelling reasons
> to use Subversion anymore, except the ability to check out only
> subdirectories from a branch and the insistence that a single central
> repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.

That's what a git tag is for, or a distinct and locked down repo in a submodule.

> I have never once found that feature to be useful since I first used
> Subversion back around 2001.  Mind you, I'd treat Word documents as
> binaries objects and not consider them suitable for incremental
> changes in a source control system.
>
>
> X: There's this useful feature that  has but  doesn't.
> Y: I've never used that feature so it's useless.
>
> You gotta love that kind of reasoning.

Not quite. The lack of any requirement for it in more than 20 years of
professional support of environments which used it, all of which have
now migrated to git, indicates that it's not a popular feature. It's
also a practice that can be duplicated by other means.

RE: [ANNOUNCE] Apache Subversion 1.14.3 released

[Juan Gabriel Covas]

>Hosting providers such as github, are abandoning Subversion support.
>It is really on its last legs:

So it's a lot of old, boring technology too, but still used because it just 
works and it's battle-tested.

I studied and deployed SVN for my team 8 years ago, after using it as an user a 
lot. "Everybody" was already using git back then. SVN serves us well, we branch 
when needed and use trunk/release branches when needed (the merge hell myth is 
still around). 

For my team particularly, we don't see the need (effort) to migrate, although 
everybody has the usual github account/usage for other stuff. We keep our 
Subversion server, backups and administration pretty private, with no "external 
hosting" and the like.

My two cents,

Juan

Re: [ANNOUNCE] Apache Subversion 1.14.3 released

[Nico Kadel-Garcia]

On Tue, Jan 16, 2024 at 4:08 PM Daniel Sahlberg
 wrote:
>
> Den mån 15 jan. 2024 kl 20:44 skrev Dunnill, Robert :
>>
>> Is a document available on how to update Apache under Subversion Edge?
>
>
> I think that Subversion Edge is no longer supported (we removed the download 
> links a while back) so you should probably update to another Subversion 
> server solution or even switching to a hosting provider. But it is probably 
> better to ask this question directly to CollabNet (now digital.ai), at least 
> if you have a commercial license.
>
> Kind regards,
> Daniel

Hosting providers such as github, are abandoning Subversion support.
It is really on its last legs:

Re: [ANNOUNCE] Apache Subversion 1.14.3 released

[Mark Phippard]

On Tue, Jan 16, 2024 at 4:08 PM Daniel Sahlberg
 wrote:
>
> Den mån 15 jan. 2024 kl 20:44 skrev Dunnill, Robert :
>>
>> Is a document available on how to update Apache under Subversion Edge?
>
>
> I think that Subversion Edge is no longer supported (we removed the download 
> links a while back) so you should probably update to another Subversion 
> server solution or even switching to a hosting provider. But it is probably 
> better to ask this question directly to CollabNet (now digital.ai), at least 
> if you have a commercial license.

+1, it has not been maintained since I parted ways with CollabNet 3
years ago and even then it had probably been 5+ years since I had an
engineering team working on it. You also cannot simply replace the
binaries with someone else's as it required them to be built a
specific way so we could support so many different OS as well as the
Python bindings it included for ViewVC.

I do not think the version of SVN is really that critical to upgrade
as most improvements happen on the client, but given that the versions
of Apache httpd and OpenSSL are likely ancient and full of CVE's you
should probably try to move to something else.

Mark

Re: [External] : Re: Can't connect to github anymore

[Sean McBride]

On 16 Jan 2024, at 15:44, Daniel Sahlberg wrote:

> TortoiseSVN, the Windows client, has some scripts that actually allow 
> "diffing" of Word and Excel documents.

So does Araxis Merge (not affiliated, just a happy customer).

Sean

Re: [ANNOUNCE] Apache Subversion 1.14.3 released

[Daniel Sahlberg]

Den mån 15 jan. 2024 kl 20:44 skrev Dunnill, Robert :

> Is a document available on how to update Apache under Subversion Edge?
>

I think that Subversion Edge is no longer supported (we removed the
download links a while back) so you should probably update to another
Subversion server solution or even switching to a hosting provider. But it
is probably better to ask this question directly to CollabNet (now
digital.ai), at least if you have a commercial license.

Kind regards,
Daniel



>
> RD
>
> -Original Message-
> From: hartmannat...@apache.org 
> Sent: Thursday, December 28, 2023 9:00 PM
> To: annou...@subversion.apache.org; users@subversion.apache.org;
> d...@subversion.apache.org
> Subject: [ANNOUNCE] Apache Subversion 1.14.3 released
>
> [You don't often get email from hartmannat...@apache.org. Learn why this
> is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> EXTERNAL EMAIL
>
> I'm happy to announce the release of Apache Subversion 1.14.3.
> Please choose the mirror closest to you by visiting:
>
> https://subversion.apache.org/download.cgi#recommended-release
>
> This is a stable bugfix release of the Apache Subversion open source
> version control system.
>
> SHA-512 checksums are available at:
>
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.sha512
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.sha512
> https://www.apache.org/dist/subversion/subversion-1.14.3.zip.sha512
>
> PGP Signatures are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.asc
> https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.asc
> https://www.apache.org/dist/subversion/subversion-1.14.3.zip.asc
>
> For this release, the following people have provided PGP signatures:
>
>Nathan Hartman (CODE SIGNING KEY) [rsa4096/583F00ADF981C39F] with
> fingerprint:
> 3F8E 467C B336 6E30 13E1  120D 583F 00AD F981 C39F
>Stefan Sperling [dsa1024/E5D30273F59D25F0] with fingerprint:
> B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0
>Daniel Sahlberg [rsa3072/28DB47329CFFDC63] with fingerprint:
> 4FFC B55C 0D0D 9343 CFB4  611F 28DB 4732 9CFF DC63
>Evgeny Kotkov [rsa4096/B64FFF1209F9FA74] with fingerprint:
> E7B2 A7F4 EC28 BE9F F8B3  8BA4 B64F FF12 09F9 FA74
>Johan Corveleyn [rsa4096/B59CE6D6010C8AAD] with fingerprint:
> 8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD
>
> These public keys are available at:
>
> https://www.apache.org/dist/subversion/subversion-1.14.3.KEYS
>
> Release notes for the 1.14.x release series may be found at:
>
> https://subversion.apache.org/docs/release-notes/1.14.html
>
> You can find the list of changes between 1.14.3 and earlier versions at:
>
> https://svn.apache.org/repos/asf/subversion/tags/1.14.3/CHANGES
>
> Questions, comments, and bug reports to users@subversion.apache.org.
>
> Thanks,
> - The Subversion Team
>
> --
> To unsubscribe, please see:
>
> https://subversion.apache.org/mailing-lists.html#unsubscribing
> [Sage]
>
> The information contained in this email transmission may constitute
> confidential information. If you are not the intended recipient, please
> take notice that reuse of the information is prohibited.
>
>

Re: [External] : Re: Can't connect to github anymore

[Daniel Sahlberg]

Den tis 16 jan. 2024 kl 19:58 skrev Trent Fisher :

>
> On 1/14/2024 2:52 PM, Nico Kadel-Garcia wrote:
>
> On Sun, Jan 14, 2024 at 2:27 PM sean  
>  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
>
> There are not many compelling reasons
> to use Subversion anymore, except the ability to check out only
> subdirectories from a branch and the insistence that a single central
> repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.
>
> I have never once found that feature to be useful since I first used
> Subversion back around 2001.  Mind you, I'd treat Word documents as
> binaries objects and not consider them suitable for incremental
> changes in a source control system.
>
> There are numerous documentation teams who I have worked with over the
> years who would differ with this. Version control is essential for their
> files (they may not be able to directly compare them, but they can tell
> when changes were made and who made them), and having locking is the only
> way to make this work (which is one of the reasons why Git will never work
> for them).
>
> However, I would agree with you that binaries generated from some other
> source document is not appropriate for version control (e.g. checking in
> PDF versions of documents), but Word documents are the primary source
> documents, therefore needing version control.
>
> Before I got these teams on to SVN, they were storing everything in a
> shared folder with numerous old copies of each document laying around (e.g.
> foo.doc, foo.doc.old, foo.doc.1jun2013, foo.doc.bak, etc), which is an
> accident waiting to happen.
>
>
TortoiseSVN, the Windows client, has some scripts that actually allow
"diffing" of Word and Excel documents. It is not perfect (and big
formatting changes can really throw you off) but it is quite good and helps
if you need to use DOCX or XLSX as your "source". For Word, it uses a
built-in comparison feature and for Excel it uses conditional formatting to
highlight changes.

Kind regards,
Daniel

Re: [External] : Re: Can't connect to github anymore

[Trent Fisher]

On 1/14/2024 2:52 PM, Nico Kadel-Garcia wrote:

On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:

On 2024-01-13 16:11, Nico Kadel-Garcia wrote:


There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.

The ability to `svn lock` files is very useful if your repo has a lot of
non-mergeable files, like say MS Office documents.

I have never once found that feature to be useful since I first used
Subversion back around 2001.  Mind you, I'd treat Word documents as
binaries objects and not consider them suitable for incremental
changes in a source control system.


There are numerous documentation teams who I have worked with over the 
years who would differ with this. Version control is essential for their 
files (they may not be able to directly compare them, but they can tell 
when changes were made and who made them), and having locking is the 
only way to make this work (which is one of the reasons why Git will 
never work for them).


However, I would agree with you that binaries generated from some other 
source document is not appropriate for version control (e.g. checking in 
PDF versions of documents), but Word documents are the primary source 
documents, therefore needing version control.


Before I got these teams on to SVN, they were storing everything in a 
shared folder with numerous old copies of each document laying around 
(e.g. foo.doc, foo.doc.old, foo.doc.1jun2013, foo.doc.bak, etc), which 
is an accident waiting to happen.

RE: [ANNOUNCE] Apache Subversion 1.14.3 released

[Dunnill, Robert]

Is a document available on how to update Apache under Subversion Edge?

RD

-Original Message-
From: hartmannat...@apache.org 
Sent: Thursday, December 28, 2023 9:00 PM
To: annou...@subversion.apache.org; users@subversion.apache.org; 
d...@subversion.apache.org
Subject: [ANNOUNCE] Apache Subversion 1.14.3 released

[You don't often get email from hartmannat...@apache.org. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

EXTERNAL EMAIL

I'm happy to announce the release of Apache Subversion 1.14.3.
Please choose the mirror closest to you by visiting:

https://subversion.apache.org/download.cgi#recommended-release

This is a stable bugfix release of the Apache Subversion open source version 
control system.

SHA-512 checksums are available at:

https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.sha512
https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.sha512
https://www.apache.org/dist/subversion/subversion-1.14.3.zip.sha512

PGP Signatures are available at:

https://www.apache.org/dist/subversion/subversion-1.14.3.tar.bz2.asc
https://www.apache.org/dist/subversion/subversion-1.14.3.tar.gz.asc
https://www.apache.org/dist/subversion/subversion-1.14.3.zip.asc

For this release, the following people have provided PGP signatures:

   Nathan Hartman (CODE SIGNING KEY) [rsa4096/583F00ADF981C39F] with 
fingerprint:
3F8E 467C B336 6E30 13E1  120D 583F 00AD F981 C39F
   Stefan Sperling [dsa1024/E5D30273F59D25F0] with fingerprint:
B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0
   Daniel Sahlberg [rsa3072/28DB47329CFFDC63] with fingerprint:
4FFC B55C 0D0D 9343 CFB4  611F 28DB 4732 9CFF DC63
   Evgeny Kotkov [rsa4096/B64FFF1209F9FA74] with fingerprint:
E7B2 A7F4 EC28 BE9F F8B3  8BA4 B64F FF12 09F9 FA74
   Johan Corveleyn [rsa4096/B59CE6D6010C8AAD] with fingerprint:
8AA2 C10E EAAD 44F9 6972  7AEA B59C E6D6 010C 8AAD

These public keys are available at:

https://www.apache.org/dist/subversion/subversion-1.14.3.KEYS

Release notes for the 1.14.x release series may be found at:

https://subversion.apache.org/docs/release-notes/1.14.html

You can find the list of changes between 1.14.3 and earlier versions at:

https://svn.apache.org/repos/asf/subversion/tags/1.14.3/CHANGES

Questions, comments, and bug reports to users@subversion.apache.org.

Thanks,
- The Subversion Team

--
To unsubscribe, please see:

https://subversion.apache.org/mailing-lists.html#unsubscribing
[Sage]

The information contained in this email transmission may constitute 
confidential information. If you are not the intended recipient, please take 
notice that reuse of the information is prohibited.

Re: Can't connect to github anymore

[Branko Čibej]

On 14.01.2024 20:52, Nico Kadel-Garcia wrote:

On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:

On 2024-01-13 16:11, Nico Kadel-Garcia wrote:


There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.

The ability to `svn lock` files is very useful if your repo has a lot of
non-mergeable files, like say MS Office documents.

I have never once found that feature to be useful since I first used
Subversion back around 2001.  Mind you, I'd treat Word documents as
binaries objects and not consider them suitable for incremental
changes in a source control system.


X: There's this useful feature that  has but  doesn't.
Y: I've never used that feature so it's useless.

You gotta love that kind of reasoning.

-- Brane

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Sun, Jan 14, 2024 at 2:27 PM sean  wrote:
>
> On 2024-01-13 16:11, Nico Kadel-Garcia wrote:
>
> > There are not many compelling reasons
> > to use Subversion anymore, except the ability to check out only
> > subdirectories from a branch and the insistence that a single central
> > repository is the only source of truth.
>
> The ability to `svn lock` files is very useful if your repo has a lot of
> non-mergeable files, like say MS Office documents.

I have never once found that feature to be useful since I first used
Subversion back around 2001.  Mind you, I'd treat Word documents as
binaries objects and not consider them suitable for incremental
changes in a source control system.

Re: Can't connect to github anymore

[sean]

On 2024-01-13 16:11, Nico Kadel-Garcia wrote:


There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.


The ability to `svn lock` files is very useful if your repo has a lot of 
non-mergeable files, like say MS Office documents.

Re: Can't connect to github anymore

[Nico Kadel-Garcia]

On Sat, Jan 13, 2024 at 4:02 PM Johan Corveleyn  wrote:
>
> On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:
> >
> > hey there
> >
> > suddenly i can't connect to github anymore (svn update or svn checkout)
> >
> > i get the following error:
> >
> > svn checkout https://github.com/roger21/fract.git
> > svn: E170013: Unable to connect to a repository at URL
> > 'https://github.com/roger21/fract.git'
> > svn: E160013: '/roger21/fract.git' path not found
>
> Apparently, GitHub has removed its support for the Subversion protocol:
>
> https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/
>
> --
> Johan

The "git-svn" module has been my go-to tool for accessing legacy
Subversion repos for some time. There are not many compelling reasons
to use Subversion anymore, except the ability to check out only
subdirectories from a branch and the insistence that a single central
repository is the only source of truth.

Re: Can't connect to github anymore

[roger21]

On 13/01/2024 20:38:18, Johan Corveleyn wrote:

On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:


hey there

suddenly i can't connect to github anymore (svn update or svn checkout)

i get the following error:

svn checkout https://github.com/roger21/fract.git
svn: E170013: Unable to connect to a repository at URL
'https://github.com/roger21/fract.git'
svn: E160013: '/roger21/fract.git' path not found


Apparently, GitHub has removed its support for the Subversion protocol:

https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/



indeed, thanks for the link

the UI still says you can use svn:

> Use Git or checkout with SVN using the web URL.

they really did nothing to communicate on this

Re: Can't connect to github anymore

[Johan Corveleyn]

On Sat, Jan 13, 2024 at 8:28 PM roger21  wrote:
>
> hey there
>
> suddenly i can't connect to github anymore (svn update or svn checkout)
>
> i get the following error:
>
> svn checkout https://github.com/roger21/fract.git
> svn: E170013: Unable to connect to a repository at URL
> 'https://github.com/roger21/fract.git'
> svn: E160013: '/roger21/fract.git' path not found

Apparently, GitHub has removed its support for the Subversion protocol:

https://github.blog/changelog/2024-01-08-subversion-has-been-sunset/

-- 
Johan

Re: Can't connect to github anymore

[roger21]

On 13/01/2024 20:28:01, roger21 wrote:

hey there

suddenly i can't connect to github anymore (svn update or svn checkout)


(snip)

apparently it's over

https://github.blog/2023-01-20-sunsetting-subversion-support/

the news could have been made louder