Opera 12.15 Source Discussion Thread

Last Thread:

Other urls found in this thread:

bitbucket.org/prestocore-fan/presto
aww.moe/z0egik.zip
paste.fedoraproject.org/526781/32598714
files.catbox.moe/4hzs77.gz)
pastebin.com/uzu3K7XB
mega.nz/#F!epZjXIwY!_Dj6Em3cnAMEojKRMNS3MQ)
site.anonnet.org/webirc/openopera
github.com/PrestoXen/openopera-issues
dobreprogramy.pl/Niech-Opera-12-bedzie-znowu-wielka-Co-anonimowi-zrobia-z-wycieklym-kodem-przegladarki,News,78524.html.
pastebin.com/UuaZSWZg
change.org/p/opera-software-open-sources-of-presto-engine
opera.com/blogs/security/2016/02/opera-12-and-opera-mail-security-update/
howsmyssl.com/
opera.com/docs/changelogs/unified/1216/
opera.com/blogs/desktop/2014/04/opera-12-17/
github.com/PrestoXen/openopera-issues/issues
paste.fedoraproject.org/528850/14846609
gist.github.com/kandeshvari/6e69327fb017ea95bced85c6f297a29f.
sourcecode.opera.com/gstreamer/
github.com/PrestoXen/openopera-issues/issues/10#issuecomment-273219715
twitter.com/SFWRedditGifs

Git repo: bitbucket.org/prestocore-fan/presto

Original leak: aww.moe/z0egik.zip

Patch for building on linux: paste.fedoraproject.org/526781/32598714
(prepatched source: files.catbox.moe/4hzs77.gz)

Windows build guide: pastebin.com/uzu3K7XB
(mega.nz folder with all the tools needed: mega.nz/#F!epZjXIwY!_Dj6Em3cnAMEojKRMNS3MQ)

If anything goes down just reply and I'll try reupping it

Exactly what do people plan to do with this? A new browser that'll probably be shit.

I plan to run it on OpenBSD, a platform it's never supported.
>A new browser that'll probably be shit.
Well considering we're starting out with the best browser I have an extremely hard time imagining it'd end up that way.

It's known botted. Applying botted patches to it probably won't help.

IRC Channel: #openopera on crowley.anonnet.org:6697
WebChat: anonnet.org/webirc/openopera

Well it's only really Sup Forums looking into it right now, so there's no 'probably' about it. But it's fun.

Anyway since you asked, what I've seen people trying to do so far:
>update source to match changes in 12.18 (adding ECC/GCM ciphers, updated certificates..)
>porting it to Pi (seems to be working already)
>porting it to Pandora
>improve browser speed/CPU usage (we don't have the profiler data that Opera used for their builds, so ours are naturally slower right now)
>and probably other shit (I saw someone getting a JS console working which was neat, also heard people were trying to integrate V8 into it)

Well now we have all the code for it, so you can point to us where the bot is

It's times like this I really wish we still had /prog/

site.anonnet.org/webirc/openopera is the correct URL for the WebChat.

It would also be nice if someone got DASH to work in Youtube, etc.

Probably need VP9 for that which I heard this doesn't support?

We really need an issue tracker or something so people know what's broke/what to try working on, doesn't bitbucker have an issue tracker or anything? If not maybe we could just start an empty repo on github for the tracker

The software exists. Thus the botnet exists until proved otherwise.

Or maybe we should put the git on Gitlab instead, they have an issue tracker etc like github does but they aren't as DMCA-whipped like github is, not sure if they're actually hosted in the US or not though.

Gitlab is open source too, maybe if someone here felt generous they could host it for us

1. You are right. VP9 is needed to be supported for DASH to work.

2. Bitbucket doesn't have an Issue Tracker. So, someone should go ahead and make an empty repo on Github for the tracker.

And it's confirmed VP9 isn't supported right? (haven't tried it myself)

Also just made a tracker, feel free to add whatever you want:
github.com/PrestoXen/openopera-issues

Post something with your github acct on there and I'll make you a collaborator too

Are you thinking of Chropera?

opera is going to catch you on github!

There's no source hosted on it though.

But they'll use it to find where the source and irc are hosted :(

Like Zero said there's no source on there, but I wouldn't be surprised if github were faggots and took us down anyway.

Not really sure the easiest way to backup the issue tracker etc, they aren't really stored in a git repo or anything, I guess we'll have to rely on archives

They probably already know by now, some faggot probably already contacted them with the thread link

Well I've added everything I can think of right now, if anyone has more suggestions feel free to add them:
github.com/PrestoXen/openopera-issues

Also if the owner of the bitbucker sees this, it'd be nice if you could link this tracker in the README. Also comment on the collaborators issue and I'll make you a collab, or just message me on IRC when I'm on

Has there been much activity from the Russians on this? I heard it came from them

I don't know. The Polish have caught on though. Take a look at dobreprogramy.pl/Niech-Opera-12-bedzie-znowu-wielka-Co-anonimowi-zrobia-z-wycieklym-kodem-przegladarki,News,78524.html.

Nice, more news sites means more eyes on it

I sent a tip into The Register about it yesterday, only linked them to the DMCA notice though but think I mentioned Sup Forums, hopefully they'll have the balls to write about it.

Did try posting on Slashdot too but the pussies removed it after a few hours, as predicted they were too scared to break the news about it, and people wonder why they're not relevant anymore

There one usefull patch for --release build on linux - pastebin.com/UuaZSWZg
Modern (gcc5-6-7) compilers may output very unstabe code.

change.org/p/opera-software-open-sources-of-presto-engine

Anyone know Polish? Someone should comment there with a link to github.com/PrestoXen/openopera-issues

I've added the IRC link to the readme there, and mentioned how to find the sources. Also added links to a lot of resources I found, if anyone has anything else to add let me know

Also if anyone does comment make sure to stress that link is just an issue tracker, and no code is there, otherwise they might think it's another source dump and remove the comment

If someone does plan on looking into upgrading the openssl version your time might be better spent with libressl. It shouldn't be much different.

I was thinking the same thing

Depends if libressl offers a 1.0.x line like OpenSSL does, they keep the API the same between minor versions but major ones like 1.1.x would be a lot different

I'd guess they probably do though, be sweet if someone does get it working

The PowerPC build flamed out. There's nothing particularly interesting in either the file mentioned or its immediate headers as far as architectures go. The header itself is a "if this flag is defined, add these members to this class" ordeal. The failure was likely due to the Linux-PowerPC-Desktop configuration being removed years ago. It probably wouldn't be to hard for someone to solve this by digging into the configuration scheme and copying the x86 Desktop configuration.

The armel build is still cooking. It was restarted about 5 hours ago. The reason it was restarted was I rewrote all of the existing anonymous patchsets to be more descriptive of their topics and to generalise some of the work. I'll publish these along with my VM setup scripts if I ever get this off the ground.

One thing I did not do for the armel build was turn on LTO. That may have made the resulting binary a bit faster, which is very much needed on old armv5 devices. However, qemu only allows a max of 256 MB for the versatilepb machine, and LTO would probably choke under those conditions. I'll start that build after I can generate bare-minimum armel deliverables.

pic related

You'd think it'd just werk when trying to compile with clang since that's the compiler for the OS X version but it throws errors while gcc would build it fine

How was arm support added so easy while PPC is much harder?

ARM wasn't really "added" since Opera has existed in mini / micro / custom forms for those devices for a long time. ARM in X11 Desktop trim is what is new, and is what Opera Software has never released publicly. Doing that was a matter of one or two well placed patches as demonstrated by the armhf build from earlier.

PowerPC existed in the past, but was removed. Some of the code paths are still there as configuration paths, but most everything else--including the topmost configurations--have already been plowed under. See modules/hardcore/base/system.txt for lots of interesting options.

The configuration system really only has three targets at the moment: i386, x86_64, and arm. To make things more technically difficult, arm doesn't have the code path to output a packaged deliverable. The configuration and delivery systems make the assumption that 32-bits==i386 and 64-bits==x86_64, which is stated in platforms/quix/module.build/gcc.conf.py and platforms/paxage/module.build/conf.py. It should be simple to expand this to other machines, but I still don't understand the build system well enough to make it do the right thing when target != host (for instance, when using a cross-compiler). It's frustrating that the only machine-type variable I've found so far is in the packaging system at "config.targetPlatform.packageArch". If the build doesn't use the packaging system, then that doesn't really help. There should be a way to derive this from the compiler or from elsewhere in the configuration system.

Any idea when they removed it? I may know a guy who has some older Opera Mobile source, though you'd think it unlikely to have much to do with PPC, as far as I know most of the code was pure Presto, so maybe we'll get lucky.

Any filenames or anything to try looking for?

So I'm thinking to make it build for OpenBSD I should just modify it to check for OpenBSD instead of FreeBSD and see where it goes from there. Can anyone help me find the specific file(s) I'd modify?

Better way - add new OpenBSD target instead of change Free one.

Got it building with VS2015 :)

Only needed some minimal changes, which are because of some dumb C++11 shit, eg string literals now have to begin with a space, like
out_sink->OutString("::"IN_STRUCT_INSTANCE_NAME" = "IN_STRUCT_INSTANCE_NAME";");

being changed to
out_sink->OutString("::" IN_STRUCT_INSTANCE_NAME" = " IN_STRUCT_INSTANCE_NAME";");


Gonna try the static analysis now, will probably find a shitload of warnings though.

If someone can give me repo access I'll push the changes I made, email is [email protected]

Do I just add the target and it works or what? I don't know, I'm just sort of finding my way through this.

When there's only three people downloading Opera Desktop for PPCLinux, it's a pretty easy management decision to cut maintenance on that item.

I'd never ask somebody to willingly leak code. That goes double if there's someone who knows he had it. Sure, it'd be nice to say, "hey, can you compare these two codebases to see if there's a backdoor?", but if they aren't from the same era, then it's a no-go.

Stuff to look for: system.txt gives a hint to look for THIRTY_TWO_BIT, which is generated in build/src/modules/hardcore/base/system.h. That pulls in existing product-specific system.h files. The obvious one for Linux Desktop stuff is in platforms/unix/product/system.h. I'd imagine that there's a whole lot of architecture switch statements that can be created or reactivated beneath platforms/unix.

Just checked and the last PPC release was in 2010, this Opera Mobile stuff is slightly earlier than that so there's a chance at least.

>Sure, it'd be nice to say, "hey, can you compare these two codebases to see if there's a backdoor?", but if they aren't from the same era, then it's a no-go.
Yeah that's true, this code even uses a completely different build system.. but a lot of the actual Presto code is the same, and it's mostly organized the same too

>I'd never ask somebody to willingly leak code. That goes double if there's someone who knows he had it.
Well I don't really think he wants to leak it all, but he'd probably give out files if you wanted them, like I said most of it is pretty much the same as what we already have, so it's not really as special anymore

I'll try asking him to look into the platforms/unix folder, so you think there might have been PPC specific code in there?

Building in Release with VS2015 seems to work too, though the Opera.exe launcher won't build because of these bastard errors, and it had to be the worst kind too, linker errors ;_;

The Opera.dll file with VS2015-debug Opera.exe works fine though, but I get the feeling it'd probably run much quicker if I can get a Release exe built

*The VS2015-release Opera.dll with VS2015-debug Opera.exe works fine

Ah figured it out, I think...

Release VS builds use a lib file called LIBCTINY.LIB, which replaces LIBC.LIB with a smaller version I guess

That tiny version is missing some exports though, so we'd either need to add them to the lib (sadly can't since source wasn't included for it), link against another lib file which contains the missing exports (if we knew what they did), or just stop it linking against that LIBCTINY.LIB and use the normal LIBC.LIB instead.

I've gone for the last option and it seems to be working, I had to stop it linking against both LIBCTINY.LIB and some nowatson.obj file though, not sure how it'll affect it.

Also gonna try x64 compiling with VS2015 in a bit, wish me luck.

Damn, i-it's fast!

Also wtf, "Detected possible malicious code in image file." when trying to upload this webm, fuck you gookmoot

Oh should probably mention that's still the x86 version, x64 is building now

Pre chromium opera was always fast. Out of head to head with its contemporaries and it will win in terms of speed and customization.

Try accessing Facebook and outlook. Com with it. Also, you're on Windows right?

Are there any known vulnerabilities for Opera 12.15+? A lot of people seem to think that the software is insecure, but I have not seen proof yet.

It is clear that Windows was Heartbleed-affected until 12.17 and the Security Team states that 12.18 brought a security update for M2, but they state that this issue only is about the standalone windows client. opera.com/blogs/security/2016/02/opera-12-and-opera-mail-security-update/

So, again: I know that some JS could make it crash, but are there real security vulnerabilities / eploits?

>Also, you're on Windows right?
Yep, compiled with VS2015 too
>Try accessing Facebook and outlook. Com with it.
Eh I don't have a FB account, but I'll try outlook out now

That's not exactly what I meant. I mean, it wouldn't surprise me if the company put some sort of fingerprint (comments reworded a certain way, spurious end-of-line spacing, some intentionally introduced non-critical warning, etc) into code provided under an NDA. That way if a file were leaked it would be very simple to look up the fingerprint against those on file and then drag the guy through the court system. So don't leak NDA material.

I have no idea about what lies beneath platforms/unix. I haven't made it that far. That and the build system (which has probably changed dramatically between 2013 and pre-2010) are the two areas where we can make new architecture gains.

Can you have uBlock Origin, noScript and Tamper/Grease Monkey installed on this Opera?

Ah right, well this wasn't obtained via NDA or anything like that, I'd like to go into it but can't much, but rest assured this didn't originate from an employee, more an unsecured server.

Also funnily enough platforms/unix doesn't seem to exist in the OM source, there's still platforms/posix though, and grepping the whole tree finds a lot of hits for "PowerPC", could just be the same remnants that are in 12.15 though, but again this code is from before they dropped PPC so there could be more here.

Anyway if you think you need an older version of a file just ask and I'll see if I can grab it for you.

I use scriptweeder as a NoScript replacement and urlfilter.ini and usercss for adblocking

Also Opera's got Violent Monkey

Damn, looks like outlooks login won't work with Opera :( Probably HTML5 shit I guess

Well, Heartbleed could theoretically impact other platforms as well. But due to the way Opera is distributed for them it is unlikely they'll ever see the problem. According to the changelog, Heartbleed affected the autoupdater and the installer. In Windows that's critical since it's the way most users update their software--direct from the company. Under most unixes it's handled by an intermediate party--the distribution maintainer or the sysadmin directly. So therefore it never mattered. It's probably still there, though.

The critical thing on 12.18 was introduction of ECC and GCM. RC4 (ARC4) is theoretically broken (and that means state actors probably break it on the regular) and a lot of webservers have turned off this protocol. The original DH *(that is, not-DHE) doesn't offer forward secrecy so it can be replayed and cracked after the fact if someone gets your keys. Just get rid of SSLv3 altogether. At one time I had a guide that described how to harden Opera 12, but I can't find it anymore.

See also howsmyssl.com/

For information:
12.16 info: opera.com/docs/changelogs/unified/1216/
12.17 info: opera.com/blogs/desktop/2014/04/opera-12-17/
12.18 info: opera.com/blogs/security/2016/02/opera-12-and-opera-mail-security-update/ (basically, support for latest HTTPS websites that use ECDSA certificates)

Some features I'd like to see in Opera 12 (apart from general support for latest web standards):
- Proper support for Hardware Acceleration for smooth experience. It's buggy for now.
- Support for Shift+Click on scrollbars.

What I hate about every recent browser (including ChrOpera):
- Forced multi-process.
- Non-native UI.
- No customization whatsoever. Addons and extensions can't fix that.
- No advanced controlling for network, content and scripting features.

IIRC, there is a hard crash if the page contains the following erroneous construction: " text "
But the only page where I could confrm this is no longer online.

Also, 12.18 introduced far more: support for latest crypto stuff (e.g. that's used on CloudFlare, LetsEncrypt etc.). Many HTTPS-only websites simply don't work on any pre-12.18 version.

firefox about:config seems pretty extensive

go to an existing page and edit the html
open a local html file
use netcat if it needs to be served via HTTP

>- Proper support for Hardware Acceleration for smooth experience. It's buggy for now.
>- Support for Shift+Click on scrollbars.
If you've got a github acct feel free to add them to the issue tracker, helps us see what people want:
github.com/PrestoXen/openopera-issues/issues

Those are not site-specific. Firefox also can't disable automatic redirection. It also can't disable frames/iframes and can't immediately switch between show-images/hide-images.
Also opera:config is nicer.

Tried that, and failed. It'll need more time to reproduce, time that I probably won't have. I only remember that it was about font and form tags.

Saw that, thanks.

You are doing God's work, anons. A shame I can't contribute as I lack C++ skills.

To the user above wondering about precompiled binaries, I'd trust them since they're pretty much as trustworthy as any official release from Opera. Kind of looking for x86 anyway since Visual Studio on my work computer likes to use a lot of RAM at times.

Finally got x64 building under VS2015, seems to work fine, but strangely Sup Forums's CSS doesn't seem to load while every other site I tried does, maybe it's just a temp issue connecting to the server or some shit.

Need to make sure though, anyone know a good site with heavy use of CSS/JS? (Other than Acid3 etc of course)

I'd suggest youtube

Hmm well it's definitely the x64 build, running the x86 one instead Sup Forums looks fine, very strange that it's only Sup Forums acting up... Could be a cache issue though I suppose.

Also to get x64 working I had to uncomment some pragmas which made some warnings turn into fatal errors, strangely under VS2010 these warnings weren't triggered at all, but under VS2015 there were hundreds of them. This is what I'd pin it on 2bh, especially considering the content of the warnings/errors:
// pointer truncation (64-bit unsafe) - Use when compiling for 64-bit to catch truncated pointers
//#pragma warning( error : 4311 )

// You attempted to assign a 32-bit value to a 64-bit type. For example, casting a 32-bit int or 32-bit long to a 64-bit pointer.
//#pragma warning( error : 4312 )

Weird how VS2010 never triggered them, perhaps these aren't in VS2010 and are just for VS2012 (which it looks like the source supports natively btw)

Good idea, I'll give it a try now

Youtube looks fine, wtf?
Also tried clearing cache and Sup Forums is still fucked up, this is weird asf.

Ah nevermind, did a full rebuild and copied it over a fresh 12.15 install and it works fine now, weird.

If anyones interested I'll put up the full x86 and x64 builds in a sec, hopefully they might run better than the official build since they're based on VS2015's runtime now (probably not though since we still aren't PGO yet)

Have you looked at the requests made to 4cdn.org? I think that's where JS/CSS is loaded from.

I was too late. Glad you got it working though.

Oh god damnit, I closed it down and started it again and now the problem is back... what the fuck is going on, corrupted preferences or some shit?
Not yet, gonna check it out now

I had the same problem with 12.18 x64 specifically on Sup Forums at some point. Had to switch style at the bottom of the page sometimes to fix it. Now it's gone, but I still have no idea what caused that. If you can, try official 12.18 (use portable installation mode for cleanness). If it's same, my guess is that you will have serious problems trying to reproduce this bug on any other website.

Well checking with Fiddler it looks like it's making all the proper requests for the css files etc, but just doesn't want to use them...

No idea how I had it working that one time, I've tried recreating how I did it:
>uninstall all opera copies
>reinstall opera 12.15
>copy 12.15 folder to somewhere else
>rebuild 12.15
>overwrite exe/dll with compiled one

No dice, ughh. I'm too tired for this, I'll probably just release the patch for VS2015 building and leave it till tomorrow or something

Well maybe I'll try doing the above one more time

Interesting, I guess it could just be a fault with all x64 builds then maybe
I'll try giving it a go now, thanks for the heads up

Chromium doesn't have this problem.

Fork it.
Operium.

Damn, seems like the official builds have no trouble with it...
And of course my rebuilt one still has the problem, what the fuck
Guess I should check what happens with VS2010-x64

Tried out the style switcher and that actually seemed to work, but if I switched to a style, switched to another and then switched back it'd break the style.

If I switch it to Yotsuba instead of default Yotsuba B though I can refresh and it never breaks, but with Yotsuba B it breaks like 90% of the time when refreshing.

I guess maybe it's just a Sup Forums issue, but it's weird that the x86 and official x64 builds don't seem to have this problem..

No shit. Chromium is too busy being Chromium.

I certainly remember being able to reproduce this problem with official builds. Not anymore. The default style was Yotsuba that time though.

Sup.
VP9 patch: paste.fedoraproject.org/528850/14846609
You'll need to update bundled libvpx to 1.3.0 first

Does this build on Vista?
I've got a Vista shitposting machine that I occasionally use and I'm running Chrome 40 on it (because newer versions remove the aero glass)

That's linux only, win projects need updating.

Shit dud.

Builds under Win7 fine, probably will for Vista too

Cool, I'll give it a shot

A Russian has managed to get it to compile for FreeBSD v11. The patch and command to run is available at gist.github.com/kandeshvari/6e69327fb017ea95bced85c6f297a29f.

Alright, finally narrowed down my fucked-up-Sup Forums-x64-build problem.

Seems to have something to do with the launcher exe, with the one created by VS2015 it takes a solid minute to load up, and then Sup Forums's CSS is all fucked.

But if I replace that launcher exe with one made by VS2010, and keep the Opera.dll from VS2015, it launches almost instantly with no CSS issues.

Now I just need to find what's wrong with it, I mentioned here () about what I had to do to get the launcher exe compiling, which involved switching the libc they were using for the default one, and removing a "nowatson.obj" file from being linked to it. Guess they must have been important in some way, hmm.

Here's an interesting comment from another Russian:

"Patch to support VP9: paste.fedoraproject.org/528850/14846609 First, you need to update the firmware to 1.3.0 libvpx The patch to the Linux only, sorry."

I can't wait till someone makes a version that's close to the DS opera browser. It'll be ultra minimal.

Neat, looks like it wouldn't break building for other OS's neither
That was just posted here, I missed it at first too: I wonder what makes it Linux only though, once I get this x64 crap fixed I'll try looking into it (very close now, solved the problem in my last post I think)

Are you guys fucking retarded? Do you *want* to get sued?

I really doubt a company like Opera is going to waste money on a lawsuit against some unemployed Sup Forumstards, what would they have to gain from that? A simple cease and desist would be enough, much cheaper for them and less headache for both parties.

Also Opera's userbase isn't exactly growing, I don't think a lawsuit against some dedicated users would be helping it.

Besides, I'd think that they'd be going after the leaker right now seeing as there's a chance he could leak again.

>what makes it Linux only
It's simple. Linux version compiles gstreamer plugins from source.
Windows version, however, uses prebuilt gstreamer in adjunct/desktop_gstreamer/
I don't know if that's a vanilla version or patched

Ah damn, noticed a lot of Windows libraries in here are prebuilt, sucks ass

Luckily they host their custom gstreamer version on their site it seems:
>This directory contains binaries of GStreamer libraries and plugins
>for platforms that do not natively include them. The source code can
>be downloaded from sourcecode.opera.com/gstreamer/

Shouldn't be too hard to build it hopefully

We should search for all the good feature requests from the old forums:

- pgp for mail.
- per site proxy
- find hidden option to activate face gestures / make browser brew coffee

> We should search for all the good feature requests from the old forums
And what? You will implement all those "I want!" features?

Think I finally fixed the VS2015-Sup Forums bug, and by fixed I mean hacked around it, you can read my explanation here if you're interested:

github.com/PrestoXen/openopera-issues/issues/10#issuecomment-273219715

>sourcecode.opera.com/gstreamer/
None of the repos there seem to clone properly for me when I use "git submodule update --init", looks like they removed them ;_;
Anyone here got a copy of them?

I'm probably doing something wrong, but after copying the latest libvpx from their github to platforms/media_backends and applying the patch, I get a ton of errors when trying to build it, like:
./platforms/media_backends/libvpx/vpx/./vp8.h: In function ‘vpx_codec_control_VP8_SET_DBG_COLOR_REF_FRAME’:
./platforms/media_backends/libvpx/vpx/./vpx_codec.h:431:36: error: expected declaration specifiers before ‘DEPRECATED’
vpx_codec_ctx_t *, int, typ) DEPRECATED UNUSED;
Any help would be nice