Closed SpotlightKid closed 2 years ago
I do appreciate the suggestion. But I'm afraid Edisyn's binaries have to be hosted in this location for the foreseeable future, as it's the primary server for the computer science department in which I work, and for certain space reasons the binaries can't be hosted on github proper. I must warn you that there's no guarantee that this location will be consistent or permanent, though I imagine it will be consistent for the time being. I will mention to the powers that be that their SSL certificate has expired though.
On Feb 14, 2022, at 8:01 PM, Christopher Arndt @. @.>> wrote:
I maintain the edisyn-bin https://secure-web.cisco.com/15gBIEO6ClW07XWMI6M1vfJiphM5Rt__fyErxv9mCk6NMthpo8-kIA_o5piVYgx0uFM1QHOcjCNj2rCJcneSg9r7Q7AcrWQD8OUV_G0ZtnD6NM4ShQdp-IcKgjlZMlMTla7x78_EdnYdSPhUoe-q7VyAeG_S6WDiJhM750_oFjn3_LEmQFwZ5YEVpY3DK_P7qPUoAu-A5mEkVqWYglUA9YlqYt7wRknQ7lgOcrEEENue9Zfwmey5RD7SqNBLj-kf9jT6_3vnTXFcY5GcYEEeCm8HAlEVAl0j8Cla-7R2Br46wTUGLMc1GEdfjJoCjVnQxFI1YuHjY7FANJFwu-1imE3ceqzDSLb0i4MrVLGKqr_v9DBypb6D-ldu5xSWi771gyadAzoWlIDAbeM2FMEGHwd0o2N2blOJHyZeroDqMTZlPO1gR14Zr0lqfm0gJPqK9/https%3A%2F%2Faur.archlinux.org%2Fpackages%2Fedisyn-bin package in the Arch User Repository (AUR), which downloads and installs the provided edisyn.jar https://cs.gmu.edu/~eclab/projects/edisyn/edisyn.jar.
Since sometime recently, curl complains that it can not verify the SSL certificate of the server, which hosts this file (cs.gmu.edu http://cs.gmu.edu/). Thus the package build process can not proceed and the package build fails.
curl -v -O https://cs.gmu.edu/~eclab/projects/edisyn/edisyn.jar https://cs.gmu.edu/~eclab/projects/edisyn/edisyn.jar % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Trying 129.174.125.139:443... 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 Connected to cs.gmu.edu http://cs.gmu.edu/ (129.174.125.139) port 443 (#0)
- ALPN, offering h2
- ALPN, offering http/1.1
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: none } [5 bytes data]
- TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data]
- TLSv1.3 (IN), TLS handshake, Server hello (2): { [108 bytes data]
- TLSv1.2 (IN), TLS handshake, Certificate (11): { [1735 bytes data]
- TLSv1.2 (OUT), TLS alert, unknown CA (560): } [2 bytes data]
- SSL certificate problem: unable to get local issuer certificate 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
- Closing connection 0 curl: (60) SSL certificate problem: unable to get local issuer certificate More details here: https://curl.se/docs/sslcerts.html https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above. It seems that this server is mis-configured, because it only sends part of the certificate chain:
SSL Server Test for cs.gmu.edu https://secure-web.cisco.com/14bpA6CMtHhd8vOFDoGLcg7aUF4-10iB1NA13vbhvQLTOdpyOXTAo_61c5JvZJGJaXfmh5gTlPVpf7oSAP_yQD-cWtt0duG0ZRNyQwyGUxdJ5biYbkMG_ztHnACnkmYsGPArwM7dLcd0KbgdDH-9yCvJF3b9jp9GGmmknSAYuNWiZbITolUh51f3FV4NdRuvQ2wsT68RZJamfH4xbv7vHGY4DL87L4X-59edyPg2Ma3kuP4wCDx5QU6ySFCyvrm1O3nLiTzdesixx9dzEVa6a1xGqNKOuiImqVeIusajCzrl7FyYOjQ1megVnAXriAnrui0yaql85iaejipZ6OBmj7SKMZtas_grl0B5ONIbkVoozuRo1Rk3wPWQKA62lfdOqtuiMW_gT-m4FPUAGjFdvegW8ZA7nYWN9vMTfcAU6kSKlPymJQ75M9fn7dzNe8Ivd/https%3A%2F%2Fwww.ssllabs.com%2Fssltest%2Fanalyze.html%3Fd%3Dcs.gmu.edu My suggestion would be to just host the edisyn.jar file elsewhere. For example, you could tag a version in Git, create a release on Github for that tag and attach the JAR file to this release. This could all be done via the Github web interface, no local git needed (since you mentioned you use SVN locally).
— Reply to this email directly, view it on GitHub https://secure-web.cisco.com/1hlFoTUuQ5YtHhfg-8Uh9GnQwMr0C37vpSkh5qAsVC7C6UIZF__GcIwt6CBRyGUkWL9useFEY7cCnlNdh7B_isjkHMJSiR3Al0JP6mrQNhb-j6Rw9wRGCcKbqubK-6xk74OVRccHxPz-xc0oL8hHwIHTav8KQBzTSV3no0WGuIPX7mURukSGC5eHR9_nQrfIhnod7cbffcGfSuPuxyJhVw5_Y8oRT03bK537lLAa0qA-OHzMWblCL5XYMfG6Z3aqGUQ0xxfOBegFY4VYV0mgcYxaMtnnyNM3ydslmweF7yTcCCEVHv02LiaZ-P675JWYb6NEWWat0bjKYl8hB0LwSeltnIdoVLIG-hmYhCMTbtmJmCBYxg3qDbseF0BP2Lj98ZbiILmKN2fxSJjJXzVv08iojSG4cMSOBLRf7C7ogenSj_HfUaUHpWubXtspegVkG/https%3A%2F%2Fgithub.com%2Feclab%2Fedisyn%2Fissues%2F48, or unsubscribe https://secure-web.cisco.com/1bW9kNVr3j7K0vRrp-n06z3D6qo6usQz3-dJ52HypMUBl64hDMjjqDlRmtnvJCVpJs1YKTueydm3fMZu5oI8CI2y-CvwvgVI6_SH6evT-8p9WkDbdjiKwY5WgxmJ5fcH0q4_2M0nTjzAKcfgDARAI-vhA-dL1NhUKsmG1MvXrg006rw0r2Fj8-vsib1J-uIBI2v-1U3AY9gVsuyh0G8zLUO17reOmR-BEjA-YRuPuGH6TqrJOyu2x-p-efKuGk7ja6KkCxaeZfgH!%20P4CuMa953i9IfP8ge1f4zHGiWk3NZpBdoaBZfodIZrEu8Vba6-94lRzqp1FBd3fCkovmA0X-B1BS6WvsfSdR8geU36wnJJFKrhP62IfkwCGl_OcjGvc4OMGJc7Xl9BRJKmb6tzTrS4hsIJDoWMIaG4oS0qa-3kXH4OHT1xqzzHRzBaKSDypkQ/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADAZDVDVDFWPZH6T3ZXJRCLU3GQUZANCNFSM5ONBFZWQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you are subscribed to this thread.
Thanks for the explanation. This is unfortunate, though, since it means, that this binary distribution can not be packaged for Arch (and probably not for any other Linux distro either). I also cannot make a package, which builds from the sources for a particular release, simply because their is neither a source distribution archive, nor a git tag or anything, which identifies a certain state of the sources as a particular release. The best I can do is make a VCS AUR package, which builds the latest git version, whatever that is at a particular time.
GMU is confused by this. They tell me that the certs for cs.gmu.edu http://cs.gmu.edu/ and .cs.gmu.edu http://cs.gmu.edu/ were renewed this past October. It is the case that the wildcard certificate for .vse.gmu.edu http://vse.gmu.edu/, which points to the same machine, expired on 2/13 expired, and they've fixed this; but they do not know why this would affect curl. At any rate, I just did the same curl test:
curl -v -O https://cs.gmu.edu/~eclab/projects/edisyn/edisyn.jar <https://cs.gmu.edu/~eclab/projects/edisyn/edisyn.jar>
... and it seems to work fine; please verify.
On Feb 15, 2022, at 2:46 AM, Christopher Arndt @. @.>> wrote:
Thanks for the explanation. This is unfortunate, though, since it means, that this binary distribution can not be packaged for Arch (and probably not for any other Linux distro either). I also cannot make a package, which builds from the sources for a particular release, simply because their is neither a source distribution archive, nor a git tag or anything, which identifies a certain state of the sources as a particular release. The best I can do is make a VCS AUR package, which builds the latest git version, whatever that is at a particular time.
— Reply to this email directly, view it on GitHub https://secure-web.cisco.com/1QtQFOz13Z7Tj_jnB8ZBJflVRb4e3ZduQ2HMQPxFw_4ciCX4Wnfm2zmfp3bmX7V_L1nIHpAmseWihCcWdlAqtzr_kUHpviiGTjFY6pajG8_mxVvSQ4mXaIv_P3QB0pgGvL7B37yc_kqiKzWyLXBXzrG-GLSpkswZFfYAT1047m6RjwFNrl1MHpZMHG3-ltU3Je07etDNUlVpjKTseDtiaV75NAzuNmTdoABVHvLQEO0I3M63s4vAuSvHT07rNdDsf6X320M-JSO1YJQDH-UjXuLDSpzNHb5WdVj5TzJ1b4e4K9ExdO5R2k4jQhICRhD8JHFwBaOZC1X3yVy8rrzCV10nygg34skE8I2UCz_Xz7jYZKCDjFXKLwBsqpo4fDCrfibRUZ91bKdRvqHkaOV_vnRu1km29VaUti5z1CfrAxlpVwIXwcfUvNvau3tysdF38/https%3A%2F%2Fgithub.com%2Feclab%2Fedisyn%2Fissues%2F48%23issuecomment-1039953424, or unsubscribe https://secure-web.cisco.com/1ArRbuptx4iWF3nilEI64fWmRLQTSdx98lRxaYZD4LX5dn5P3Kng8aCdUXdPXrGAVL2CMP6Pk-G2fLY3v2nwACJz2kbbTTHjJ0o2_QG1Z5P8Lfg35shonDnUpaPD2rheRH5obZb9JWgzGGY0Ntj-JKLl77y22tvZM76m28rBaYNJGsPFKIasjiXJRc81k4YIzTV4ExYvXZ-gpo1BPaR4nSQNFxxdMjzFSDgbMc00rY_zDsypXK!%20DDbRi14-CyvdZyEw7DJnrmed0TtR7F9_nEEnNfO3wf8KhFu9CtT5Czod-siv37hwntrAkHJ3ovsK3eK-7MV0VQPcO2qmNiIaWxG6cf_XRHpSbTEW0TK1cx6YFxuQza4Q7ZRjoiaBjrkiUkeCiGeJqlGysetGF5cvUF9dDVbG_UYBE5I8AB1f_cKVtUjrGMVSAVj2AFujF8b0dXB/https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADAZDVGS5LCRCDA7UDFN4ITU3IAEHANCNFSM5ONBFZWQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.
The problem is not an expired certificate, it seems to be that the server does not send the intermediary certificates between the server cert and the root CA cert. If you direct the GMU team to the SSL server test I linked above, they should be able to identity the problem, I think.
The curl command you tried does not use HTTPS but HTTP, so issues with the cert will not manifest themselves there. :)
Hmmm, the curl command was a cut and paste of what you had sent...
At any rate, here's what I got back from GMU's network team:
We've seen this on a few Linux boxes that connect via SSL/TLS to machines
with a cert issued by InCommon (where all of GMU gets their certs issued).
I'm not sure why the Linux distros don't get the same CA trust packages that
the web browsers get. It can be fixed on the client side on a Red Hat/CentOS/Rocky/Alma
linux distro by putting the attached file (which contains certs that connect the
InCommon CA to a known trusted CA) in
/etc/pki/ca-trust/source/anchors
and running the command
update-ca-trust
What do you think?
I'm told by my admin team that they have added the InCommon intermediate certs to the trust chain for the server, and have replaced the SSL cert for cs.gmu.edu with a file that includes the intermediate certs. It might patch things up.
Hmmm, the curl command was a cut and paste of what you had sent...
I think you left out the https://
part.
I'm told by my admin team that they have added the InCommon intermediate certs to the trust chain for the server,
Anyway, that fixed the issue.
Many thanks!
I maintain the edisyn-bin package in the Arch User Repository (AUR), which downloads and installs the provided edisyn.jar.
Since sometime recently, curl (which is used in the package build process by
makepkg
to downloadedisyn.jar
) complains that it can not verify the SSL certificate of the server, which hosts this file (cs.gmu.edu). Thus the package build process can not proceed and the package build fails.It seems that this server is mis-configured, because it only sends part of the certificate chain:
SSL Server Test for cs.gmu.edu
My suggestion would be to just host the
edisyn.jar
file elsewhere. For example, you could tag a version in Git (which would be very helpful in any case), create a release on Github for that tag and attach the JAR file to this release. This could all be done via the Github web interface, no local git needed (since you mentioned you use SVN locally).