Just check these directories: Squeak-3.10-1/platforms/Cross/plugins/JPEGReadWriter2Plugin Squeak-3.10-1/platforms/Cross/plugins/Mpeg3Plugin/libmpeg Squeak-3.10-1/platforms/Cross/plugins/RePlugin I haven't checked the bundled versions for known vulnerabilities, but anyway something should be done. Thanks, Diego
I don't follow, something like what?
Something like making it use system libraries instead.
Squeak is a whole system, and these are their system libraries.
Squeak provides system bindings to libraries, but it should not use bundled libraries for that.
It's how Squeak works. You should file a bug upstream. I am closing this.
For sure it's not fixed. And it's a breach of policy to use the bundled libraries unless there are very very good reasons to do so. "That's how upstream does it" it's rarely a good enough reason. Often enough upstream does so because they don't know better.
There is no benefit , instead , bunch of issues to deal with and error prone situations using system libraries for this. Squeak, as I said, it is a whole different system, and it requires special plugins, specifically written for it; seriously, there is no point of taking these libraries from system. Either you come out with a sane and SAFE way of getting these plugins on the fly (which I still would consider adding) or stop re-opening this bug.
I'm not telling you to get rid of the plugins, but since I don't see much changes out of a quick look at the sources, I bet the plugins can be linked against the system copy of the libraries, and then squeak can load its plugins using those like we do for any other language (Perl, Python, PHP, Ruby, you name it). As for "no benefit": GLSA 200701-05, GLSA 200508-17, and what about the future? What makes Squeak so tremendously different from Perl, Python, PHP, Ruby, TCL, that it cannot use the system libraries for its bindings? "is a whole system" does not really say much, since they are bindings, whether they come in a single huge package or not.
Squeak is neither python, ruby, perl, or any other language out there .... Squeak is an Operating-System like language, that contains plenty of plugins maintained by the same Squeak community. Which means that when an user _installs_ Squeak, the user intends to use those plugins, the ones written by the Squeak community. I don't agree with Gentoo changing this situation, it is a very different situation than other language, where they intend to use any library from the host system. So, please, drop this bug already since there is no benefit or point. This is pretty much something up to the Squeak community, I don't intend to re-write or fork Squeak or duplicate work here.
This has nothing to do with the plugins. This has to do with squeak repackaging libraries that it should not be. Please stop closing this as invalid since its completely valid. Any package that we install should be using the system versions of the libraries, like libjpeg, libpcre, etc. Thanks
(In reply to comment #10) > This has nothing to do with the plugins. This has to do with squeak > repackaging libraries that it should not be. Then complain with squeak. Stop re-opening this bug please. Thanks,
If we have to complain upstream, we will do so, but keep this open because the problem is NOT resolved. Thanks
I will keep this open if you want... but I thought upstream bugs were supposed to be filled to upstream and not here.
Just wanted to help araujo in followup on this. He's going to open upstream bugs for the issues, and glancing at it myself, for jpeg+libgsm+pcre there don't look to be actual changes to the codebase, just the squeak authors making a complete mess of including the libraries nicely. jpeg has two sets of new non-binding functions in new files, and aside from the jconfig.h and the binding files, the rest of the source is unmodified. libgsm looks unmodified, but ALL of libgsm is in a single file: sqSoundCodecPluginBasicPrims.c with binding stuff on the end. pcre - minor changes for binding only libmpeg3 - heavy changes, doesn't match up against the main libmpeg3 upstream. We also suspect that the squeak devs will probably ignore the report and never fix it to use external libraries, as they apparently mainly want users to use their binaries. After arajuo has opened the upstream bugs, I'd like to strongly suggest this bug is just marked as RESO/UPSTREAM - the amount of fixing work to really solve it is decided non-trivial. There's not much we can do as Gentoo without getting our hands really dirty.
@security: bundled jpeg is vuln. to GLSA 200606-11, do you want this hardmasked?
(In reply to comment #15) > @security: bundled jpeg is vuln. to GLSA 200606-11, do you want this > hardmasked? > pcre is vuln. to GLSA 200807-03 (verified the vuln. code is present in pcre.c)
# Samuli Suominen <ssuominen@gentoo.org> (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. libraries # GLSA 200606-11, GLSA 200807-03 and likely more # # http://bugs.gentoo.org/show_bug.cgi?id=247363 # # Removed in 60 days dev-lang/squeak
Is Squeak VM being removed from Gentoo in 60 days or is it the hardmask that is being removed?
And removed from tree.
