I will update the technical News Item as soon as the Debian maintainers fixed it. There is nothing we can do about the issue apart from nagging them about it.
Is there a way for us to "upvote" the issue so that they see it getting some traction?
To add to this mystery, I'm now having this exact same problem on two of my old PowerPC Macs. I set one of them up just last month, and never did get it to connect to Einstein. The other Mac is one that I set up a few years ago, and so it had an older version of BOINC. Today, I had to replace the hard drive after it failed. After doing a clean install of OS X Leopard and installing the current version of BOINC, it no longer connects, either. The error output from both machines is identical to what the Debian user has posted here.
To add to this mystery, I'm now having this exact same problem on two of my old PowerPC Macs. I set one of them up just last month, and never did get it to connect to Einstein. The other Mac is one that I set up a few years ago, and so it had an older version of BOINC. Today, I had to replace the hard drive after it failed. After doing a clean install of OS X Leopard and installing the current version of BOINC, it no longer connects, either. The error output from both machines is identical to what the Debian user has posted here.
OS X Leopard is very old and should not get updates anymore. Maybe your fresh install is using a very old certificate store that does not contain the root certificates needed. That would result in the same error messages.
Quote:
I suppose to further add to the mystery, this just began happening on my lone Ubuntu 14.04 system.
It's a new install (about 48 hours old) and I've not put a single update on since I got BOINC running successfully. O.o
Edit: Though now that I think about it, I did enable security auto-updating. :-\
This is not a mistery, since 14.04 updates recently adopted the ca-certificates package that removes the 1024bit certificates we need. Can you please check your openssl version? You should have 1.0.1f which may not be enough to fix the alternate chain bug. I'll try to reproduce on a fresh 14.04 LTS and file a bug report.
Would your earlier reported workaraound work (until it updates again?)
Edit: Once my limited mind (sort of) understood what it did, I answered my own question. It solved the problem (very) temporarily.
I installed a fresh Ubuntu 14.04 LTS and did a full update. I also got 1.0.1f-1ubuntu2.17 and that already solved the problem. So you don't need the workaround for Debian and it should work once you have the new openssl version released last week.
To add to this mystery, I'm now having this exact same problem on two of my old PowerPC Macs. I set one of them up just last month, and never did get it to connect to Einstein. The other Mac is one that I set up a few years ago, and so it had an older version of BOINC. Today, I had to replace the hard drive after it failed. After doing a clean install of OS X Leopard and installing the current version of BOINC, it no longer connects, either. The error output from both machines is identical to what the Debian user has posted here.
Hi Donald,
i was running in same error. First thing i was replacing file ca-bundle.crt in /Library/Application Support/BOINC Data/ with a newer one. Happy to solved the problem i start boincclient and saddly noticed error messages, we run into SSL connect error ... hmpfff...
ok looks like openssl 0.9.7... is now really EOL, means old/latest BOINC Manager for PPC (6.12.35) isn't support meaningful SSL/encrypted connections anymore.
But Einstein scheduler server is also available through http instead of https, this information will be provided also in /Library/Application Support/BOINC Data/ at file client_state.xml.
Quit Boincmanager/Client and open this file in Textedit or vi/nano etc. and search for scheduler_url change then protocol https:// to http:// for serveradress looks like http://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
Safe this file and start boincmanager/client it should now be able to get workunits ...
Ok i forgot to mention, user and group should be corrected after file edit back to boinc_master before starting BOINCManager cause otherwise file will be replaced with new downloaded masterfile
Example in Terminal: #sudo chown boinc_master:boinc_master /Library/Application\ Support/BOINC\ Data/client_state.xml
I'm not shure if also client_state_prev.xml in same folder should be touched, it look like a copy of client_state.xml ... i did it anyway to be shure.
After this the old BOINCManager is starting task download for our G5 grandma and pa.
RE: I will update the
)
Is there a way for us to "upvote" the issue so that they see it getting some traction?
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: Is there a way for us
)
You could send an email to bug#812488 (email address is made public!) and state that you are affected by this.
Hi Christian! To add to
)
Hi Christian!
To add to this mystery, I'm now having this exact same problem on two of my old PowerPC Macs. I set one of them up just last month, and never did get it to connect to Einstein. The other Mac is one that I set up a few years ago, and so it had an older version of BOINC. Today, I had to replace the hard drive after it failed. After doing a clean install of OS X Leopard and installing the current version of BOINC, it no longer connects, either. The error output from both machines is identical to what the Debian user has posted here.
I suppose to further add to
)
I suppose to further add to the mystery, this just began happening on my lone Ubuntu 14.04 system.
It's a new install (about 48 hours old) and I've not put a single update on since I got BOINC running successfully. O.o
Edit: Though now that I think about it, I did enable security auto-updating. :-\
RE: To add to this mystery,
)
OS X Leopard is very old and should not get updates anymore. Maybe your fresh install is using a very old certificate store that does not contain the root certificates needed. That would result in the same error messages.
This is not a mistery, since 14.04 updates recently adopted the ca-certificates package that removes the 1024bit certificates we need. Can you please check your openssl version? You should have 1.0.1f which may not be enough to fix the alternate chain bug. I'll try to reproduce on a fresh 14.04 LTS and file a bug report.
Yes, it's reported as
)
Yes, it's reported as 1.0.1f-1ubuntu2.17.
Would your earlier reported workaraound work (until it updates again?)
Edit: Once my limited mind (sort of) understood what it did, I answered my own question. It solved the problem (very) temporarily.
RE: Yes, it's reported as
)
I installed a fresh Ubuntu 14.04 LTS and did a full update. I also got 1.0.1f-1ubuntu2.17 and that already solved the problem. So you don't need the workaround for Debian and it should work once you have the new openssl version released last week.
RE: Yes, it's reported as
)
After you run the workaround above, do the following:
sudo apt-mark hold ca-certrificatesThis will hold it back. Test by doing an apt-get upgrade and you should see it reported as held back.
My YouTube Channel: https://www.youtube.com/user/KF7IJZ
Follow me on Twitter: https://twitter.com/KF7IJZ
RE: Hi Christian! To add
)
Hi Donald,
i was running in same error. First thing i was replacing file ca-bundle.crt in /Library/Application Support/BOINC Data/ with a newer one. Happy to solved the problem i start boincclient and saddly noticed error messages, we run into SSL connect error ... hmpfff...
ok looks like openssl 0.9.7... is now really EOL, means old/latest BOINC Manager for PPC (6.12.35) isn't support meaningful SSL/encrypted connections anymore.
But Einstein scheduler server is also available through http instead of https, this information will be provided also in /Library/Application Support/BOINC Data/ at file client_state.xml.
Quit Boincmanager/Client and open this file in Textedit or vi/nano etc. and search for scheduler_url change then protocol https:// to http:// for serveradress looks like http://scheduler.einsteinathome.org/EinsteinAtHome_cgi/cgi
Safe this file and start boincmanager/client it should now be able to get workunits ...
Ok i forgot to mention, user
)
Ok i forgot to mention, user and group should be corrected after file edit back to boinc_master before starting BOINCManager cause otherwise file will be replaced with new downloaded masterfile
Example in Terminal: #sudo chown boinc_master:boinc_master /Library/Application\ Support/BOINC\ Data/client_state.xml
I'm not shure if also client_state_prev.xml in same folder should be touched, it look like a copy of client_state.xml ... i did it anyway to be shure.
After this the old BOINCManager is starting task download for our G5 grandma and pa.