#29692 closed defect (invalid)
SVN checkout fails for netpbm
| Reported by: | KNIZEK.MILAN@… | Owned by: | mas@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.2 |
| Keywords: | svn, netpbm, https, http | Cc: | dazquick@…, trog24 (Frank J. R. Hanstick), ryandesign (Ryan Carsten Schmidt) |
| Port: | netpbm |
Description
SVN checkout fails for netpbm.
I tried manual svn chekout https://netpbm.svn.sourceforge.net/svnroot/netpbm/stable, which is the address from portfile, and it did not work either. After changing the address from https:// to http:// the port started to work.
The working portfile is attached.
Attachments (1)
Change History (10)
Changed 13 years ago by KNIZEK.MILAN@…
comment:1 Changed 13 years ago by jmroot (Joshua Root)
| Owner: | changed from macports-tickets@… to mas@… |
|---|
Please remember to cc the maintainer.
The current portfile fetches fine for me.
comment:2 Changed 13 years ago by mas@…
| Resolution: | → worksforme |
|---|---|
| Status: | new → closed |
You're not the first one to report intermittent svn failures from svn.sourceforge.net. This can happen both with http and with https, so changing the portfile won't do much good in the long run. Short of creating a mirror of our own, there's not much we can do about this. Sorry.
comment:3 follow-up: 4 Changed 13 years ago by dazquick@…
| Resolution: | worksforme |
|---|---|
| Status: | closed → reopened |
Sorry to reopen but I can't agree. It's inconsistent to have the url in this portfile set to https when all others I've encountered are set to http. What it meant for me was that with a fresh install of macports and installing about 20 different packages, it chokes on this one. After some snooping, it was because of a proxy issue that only affected https connections. But the error message is simply 'Subversion check out failed'. How would the user know that it's because this package is unlike others and requires a https connection? If the user has already installed multiple packages that session, I don't think they would suspect that it's an issue with subversion on their computer at all. Also, why should the user need a correctly configured https proxy just for this package? It seems to me that the decision to change it to https in the first place was arbitrary and based on a temporary issue with sourceforge which has since been rectified. Can I please request that it's changed back to http and left that way? If there's a problem with sourceforge, they should rectify it. I suspect the OP has a https proxy issue too.
comment:4 Changed 13 years ago by mas@…
| Resolution: | → wontfix |
|---|---|
| Status: | reopened → closed |
Replying to dazquick@…:
Thank you for your report. However, I won't be making this change.
I think that Subversion should not be used over HTTP at this time, as there is no good way to assure that data has not been tampered with. Portfiles that use HTTP to fetch regular tarfiles simply use a checksum to verify the integrity of the downloaded file. This is not an option when using Subversion. Transferring data over an encrypted connection using HTTPS alleviates this problem somewhat, albeit not completely fixing it (there might still have been an attack on the svn server). Completely foregoing any security just as a workaround for users whose network connection has isolated defects is not a good idea, in my humble opinion.
comment:5 Changed 13 years ago by trog24 (Frank J. R. Hanstick)
| Resolution: | wontfix |
|---|---|
| Status: | closed → reopened |
I just ran into the netpbm svn failure and this should be fixed.
comment:6 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | trog24@… ryandesign@… added |
|---|
How would you suggest we fix it?
comment:7 follow-up: 8 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | dazquick@… added |
|---|---|
| Resolution: | → invalid |
| Status: | reopened → closed |
The idea expressed here that changing netpbm's fetch from https to http will make it more likely to succeed is bizarre and backwards to me. We have in multiple other ports had to change fetching from http to https to avoid proxy problems. Proxy servers can and do interfere with http traffic and many of them do not understand the additional WebDAV HTTP verbs that Subversion uses, often resulting in fetch errors. Switching to https fixes this because https traffic is encrypted, thus proxy servers cannot decode it or mess with it.
If you are having problems fetching this or any other port that fetches from an https URL, and fetching the same port via http works fine, and you've verified it isn't just an intermittent issue, and you're using a proxy server, then contact your proxy server's administrator.
comment:8 Changed 13 years ago by dazquick@…
The issue is not http vs https. The issue is with inconsistency resulting in poor user experience, and a methodology that encourages making changes at random based on fleeting conditions. Firstly, this permanent change was made in response to a server condition that was resolved long ago. For all I know, this server problem lasted only hours or days. This does not seem to me to be good practice. Secondly, the result is that - to the end-user - the use of the https proxy is both random and rare. This is a problem even if you don't seem to agree. The result is that for the user, they may download 100 packages through their proxy and they all work, except one fails with a generic error message. They repeat with the same result. It is my expectation of a typical user that they would initially think this is a server issue, after all they have have 198 successes through their current proxy configuration. They have been given no indication that of all the packages they have downloaded this one has used a different protocol. So they'll spend some time (minutes? hours?) Googling the error message until it is suggested they locate the portfile and check the URL. Then they might notice that it is using the https protocol, compare it with other portfiles, and hopefully realise the source of the problem. This is what you'd like users to experience when using MacPorts?
You say that https is superior to http? I completely agree. If that's the case, change all portfiles to use https. Or better yet, don't specify a protocol in the portfile, check https first, then fallback to http, all the while printing messages such as 'Connecting to xxx on https: Failed', 'Connecting to xxx on http: Success'. At least there's some indication to the user what the source of the problem is on failure. The current approach of rare and seemingly random use of https with generic error messages on failure strikes me as particularly user unfriendly.
Replying to ryandesign@…:
The idea expressed here that changing netpbm's fetch from https to http will make it more likely to succeed is bizarre and backwards to me. We have in multiple other ports had to change fetching from http to https to avoid proxy problems. Proxy servers can and do interfere with http traffic and many of them do not understand the additional WebDAV HTTP verbs that Subversion uses, often resulting in fetch errors. Switching to https fixes this because https traffic is encrypted, thus proxy servers cannot decode it or mess with it.
If you are having problems fetching this or any other port that fetches from an https URL, and fetching the same port via http works fine, and you've verified it isn't just an intermittent issue, and you're using a proxy server, then contact your proxy server's administrator.
Working portfile for netpbm