Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WAExternalID raises an error when cryptography package is loaded #270

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 15 comments
Closed

Comments

@GoogleCodeExporter
Copy link

WAExternalID>>startUp causes a failure in DES>>primCookKey:mode:to:

Original issue reported on code.google.com by renggli on 5 Jan 2009 at 7:55

@GoogleCodeExporter
Copy link
Author

Original comment by renggli on 5 Jan 2009 at 7:55

  • Added labels: Version-Seaside2.9
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

To make the bug report a bit more precises: This happens when installing MySQL 
from Package Universe, that 
depends on the following version of the cryptography package: 
http://universes.dnsalias.net:8888/universes/repositories/stable-3.7/Cryptograph
y.cs.gz.

Original comment by renggli on 5 Jan 2009 at 8:12

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

You use the 3.7 stable Universe, srsly?

Can you bit a more precise? What is the error? Which version of Cryptography do 
you
use? Which VM do you use (are you sure you have the DES plugin)?

I tested with Cryptography-rww.5 (the latest from SqueakMap) and 
Cryptography-RJT.7
and they both work.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 5:43

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

This is the latest version of MySQL from the default Package Universe in Pharo.

The primitive #primCookKey:mode:to: fails.

MySQL does not load a version of Cryptography but loads a change-set named 
Cyrptography.cs. It says it is 
the version 0.3. I have the latest Mac VM.

I am not saying that there are no bugs with this setup or the packages loaded. 
I am just saying that you 
should pay attention when you introduce external dependencies to a DES class. 
Some pople might depend on 
other versions to what you are using. Some pople might have the code loaded, 
but it is not supported on their 
platform. As such this is a severe bug in Seaside.

Original comment by renggli on 6 Jan 2009 at 7:27

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Sorry, you're on the 3.7 stable Universe. The Cryptography package is obviously
broken since DES new doesn't work. Therefore it shouldn't be in the Universe in 
the
first place. Talk to the Universes maintainer. We don't support old, outdated 
and
broken libraries.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 7:42

  • Changed state: Invalid
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

No, that's the standard development Universe of Pharo. MySQL depends on this 
old version of Cryptography. 
There is nothing I can do about that.

It is your problem. Please properly check your dependencies before using them. 
Or better yet, don't depend on 
external packages at all.

Original comment by renggli on 6 Jan 2009 at 7:51

  • Changed state: Accepted
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Sure, fix the Universe. That's were the broken dependency is.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 7:59

  • Changed state: Invalid
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Philippe, please don't just close your eyes: Why do you want a dependency of 
SmaCC be removed at all cost, 
but don't bother to even think about the problems an obscure dynamic dependency 
to a particular version of 
the cryptography package in Seaside-Core might cause?

I ask you to remove this dependency from Seaside. Or at least fix it, so that 
it doesn't break when the wrong 
version of the Cryptography package is loaded.

I think it is quite common for somebody coming from PHP or Ruby to load MySQL. 
You certainly don't want 
that these people get into the situation that they screw up their image by 
loading Seaside that it cannot even 
be saved anymore.

Julian, what do you think?

Original comment by renggli on 6 Jan 2009 at 8:13

  • Changed state: Accepted
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I can remove it then we just won't have secure sessions ids anymore.

The issue here is simply that if you load a broken library then stuff break. 
This
isn't just for Cryptography. This is for everything we depend on. If you load 
an old
version of Kom then Seaside breaks as well.

Does MySQL really not work with an up to date version of Cryptography? If so 
then
MySQL isn't maintained anymore and shouldn't be loaded in the first place.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 8:19

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

MySQL breaks with a newer version of Cryptography. I will try contact the 
author.

Personally I don't care about MySQL much, but I would prefer not to scare all 
PHP/Ruby/Python people away. 
Their first question usually is if there is a working MySQL binding.

Original comment by renggli on 6 Jan 2009 at 8:57

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

I think there are more important issues than pleasing PHP/Ruby/Python people. 
If you
like PHP/Ruby/Python then use PHP/Ruby/Python. There's nothing wrong with that. 
I
think the whole business of making people and join your cargo cult is very 
misguided.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 9:42

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Why don't you create a Seaside-Squeak-Hardened package that has a declared 
dependency on a particular 
version of the Cryptography package? Exactly like we do for the Kom and Swazoo 
adapters. That would be clean. 

Having a wacky dependency to a class of an external package that might be 
present, that might be the wrong 
version, that might be broken or that might be missing altogether is just 
unprofessional. Can't you understand 
this concern?

Original comment by renggli on 6 Jan 2009 at 9:55

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Yes, it would require a WASqueakPlatform class but has the advantage that the
dependency is clear.

Original comment by philippe...@gmail.com on 6 Jan 2009 at 10:10

  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

Is work in progress. Right now it is no longer in the latest packages. I'd like 
to
keep this one open until a solution is fund that is acceptable for all parties.

Original comment by philippe...@gmail.com on 14 Jan 2009 at 7:13

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

WAExternalID is gone and WASqueakRandomProvider does not show the reported 
problem. Closed.

Original comment by renggli on 22 Feb 2009 at 8:36

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant