It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
avatar
shmerl: Sorry for off-topic. Just out of curiosity, why are you using DVDs vs let's say using a multiterrabyte hard drive or even a RAID array of several hard drives? DVDs aren't resilient for long term storage (which some don't realize until it's too late). Plus using hard drives is way more flexible and can save you the effort of burning disks each time.
avatar
Gede: There are several benefits on using optical media. Ideally he would use the DVDs in addition to the HD solution:
- They would survive an EMP blast, solar flares, minor floods and so on.
- He could carry them one game at a time to his off-site backup location, in a log cabin in the woods where he keeps a spare Pentium 3. If he gets mugged on the way, no big deal.
- He can print the cover and fill real shelves with the games (not the virtual ones). That carries huge a coolness factor! :-)
- He can also get a real sense of what it means to own 50 games he hasn't played yet.
None of the sort I assure you :D already posted the reasons above. I just grew up backing stuff on DVDs, in a sort of way I've always trusted them more than a spinning drive. It's just the way I'm used to.
avatar
shmerl: It's better idea than using game specific password but it's still not needed same as the other one.
You will see no argument from me on that. I merely wanted to say that there were similar yet less bad ways to achieve the same goal.

avatar
shmerl: By the way, which archive formats support adding files with minimal recompression? 7z / xz probably require full decompression / recompression to add even one file. FreeArc may be?
I'm under the impression that most archive formats act friendly towards the idea of adding more files. Non-solid formats may work better on updating files.
avatar
ssokolow: The key detail in making it work is ensuring that the RAR's contents are compared against something digitally signed. As long as the signature can't be forged, it's perfectly fine to store the checklist in the RAR too.
avatar
Gersen: It's possible, but then it would mean they would have to implement some custom mechanism to check this signature instead of relying on the basic signing of the executable.

I know perfectly that multiple alternative technical solution exists, even some that would be tamper proof while at the same time allowing the installer files to be extracted easily, but I think the key thing here is that (IMHO of course):

It's not some sort of evil betrayal like some make it sound, or some conspiracy about GoG trying sneakily introduce more DRMs because they are an evil corporation.

IMHO it's just that GoG wanted something easier to be able to update their installer without having to rebuild them completely, something easy to implement, easy to maintain, transparent for users and that at the same time could prevent the average Joe from accidentally extracting the bin by double clicking on them files and then complains at the support that the game wasn't working.

And the current solution is what the came up with, it might not be the most technically elegant one nor the most tamper-proof one, and I am pretty sure that are perfectly aware of that, but they probably estimated that it was an ok compromise between efficiency and development time and that it was doing the job.
My point is that we (a bunch of novices) already figured out the password. If they aren't doing signature checks, that makes the malware protection worse than useless because it gives a false sense of security.

Asymmetric crypto (signature checks) is necessary for malware protection regardless of whether the password is in use because you can't use symmetric crypto to verify the origin or authenticity of something being distributed to large numbers of people.

As for keeping Joe Schmo's browser from saying "This is a RAR", as I said, if simplicity and lack of effort is all you need, just prepend something else to the file... like a few K of EXE which does nothing but pop up a dialog saying "Download all of the parts and run the first one, not this one"

He should go to himself and demand a refund for time wasted and bad PR generated.
avatar
ssokolow: As for keeping Joe Schmo's browser from saying "This is a RAR", as I said, if simplicity and lack of effort is all you need, just prepend something else to the file... like a few K of EXE which does nothing but pop up a dialog saying "Download all of the parts and run the first one, not this one"
By curiosity how to you do that ? you cannot execute a "bin" file, so you cannot pop up anything. The only solution would be to rename the "bin" to "exe" but doing so would be a lot more confusion for peoples who would end up with a folder full of .exe files.
Post edited December 30, 2014 by Gersen
avatar
ssokolow: As for keeping Joe Schmo's browser from saying "This is a RAR", as I said, if simplicity and lack of effort is all you need, just prepend something else to the file... like a few K of EXE which does nothing but pop up a dialog saying "Download all of the parts and run the first one, not this one"
avatar
Gersen: By curiosity how to you do that ? you cannot execute a "bin" file, so you cannot pop up anything. The only solution would be to rename the "bin" to "exe" but doing so would be a lot more confusion for peoples who would end up with a folder full of .exe files.
Gowor said that some users have browsers that do header detection, resulting in the BIN files being opened as RARs.

In such a case, the simplest solution is to make the browser see it as an EXE instead using a dialog-displaying stub prepended to the file.
avatar
Gede: I'm under the impression that most archive formats act friendly towards the idea of adding more files. Non-solid formats may work better on updating files.
May be they need modification scenarios as well, not sure. I'd say really it shouldn't affect their choice of format though. The workflow and testing can involve one format, and end user result can be another (for example reduced size but solid compression).
avatar
shmerl: By the way, which archive formats support adding files with minimal recompression? 7z / xz probably require full decompression / recompression to add even one file. FreeArc may be?
According to man 7z, "-ms=on" means "solid archive = on" in an example of compressing in 7z format using "ultra settings", so I'd assume solid archiving is as optional as in RAR.
Post edited December 30, 2014 by ssokolow
avatar
ssokolow: My point is that we (a bunch of novices) already figured out the password. If they aren't doing signature checks, that makes the malware protection worse than useless because it gives a false sense of security.

Asymmetric crypto (signature checks) is necessary for malware protection regardless of whether the password is in use because you can't use symmetric crypto to verify the origin or authenticity of something being distributed to large numbers of people.

As for keeping Joe Schmo's browser from saying "This is a RAR", as I said, if simplicity and lack of effort is all you need, just prepend something else to the file... like a few K of EXE which does nothing but pop up a dialog saying "Download all of the parts and run the first one, not this one"

He should go to himself and demand a refund for time wasted and bad PR generated.
I personally prefer your earlier idea of hiding the "This is a RAR" part, without any pop ups. some people tend to get confused at the slightest error.

I'm not sure which browser identifies the bin files as rar, can't say I've ever heard about this either.

Question: I know VLC changes bin files to the cone icon if associated, does WinRAR have the same option?
avatar
Gersen: .
I want you to know that you have been stating some fair points. Don't take all the idea clashes as an indication that you are talking to a wall.

Having said that, while I am one of those who shares a very different view from yours, I do agree that this seems like a (very unfortunate) technical decision more than a strategic choice. The problem is the door which is left open.

Personally I will allow GOG a few days to review their standing on this issue, and will then act accordingly. I don't expect them to come out crying "Sorry guys! Our bad! We're dumping the work we did last month and starting anew, using only DEBs and APT." But I believe we should manifest ourselves and show how disapointed we feel right now.
Post edited December 30, 2014 by Gede
avatar
Gowor: We don't really support installing the game by manually unpacking the archives (for whatever reason you do that).
avatar
Daliz: I'll add my voice here with ssokolow - to unpack and run things in Linux, MacOS or other OS. There are many many games for sale on GOG that work great with Wine, that are only available officially for Windows (not to mention all the Dosbox games).

One way is to unpack the Win-installer as discussed in this topic - another one is to run the setup.exe in Wine. But the new GOG installers do not work in Wine properly at the moment (why I have no idea - it has changed recently, before they all worked ok).

I've bought many Win-only games and ran them myself in Wine succesfully, and I do not expect support of course. Now that I can not unpack things or even use the setup.exe, there's no point in buying really. I'll just wait and see how this unfolds.
avatar
Rixasha: Another voice against this practise in here. Same reasons as above; tinkering in Linux and with cleanroom implementations along with concern with future (and even present!) compatibility.

Please discontinue this practise. It is offensive and causes grief. I come here to avoid DRM, and I expect better from you.
Same here. It's just needlessly offending and making life harder than neccessary for all Linux users again.
Many titles here work great with Wine/DosBox or even have their own Linux native game engine recreations and not being able to get the files out of this stupid installer is really bad.
Discontinuing those blasted installers would be a bigger step towards Linuxusers than making .deb packages for every damn game individually. A simple archive with the files would make things so much easier in many ways.
Post edited December 30, 2014 by Klumpen0815
avatar
Ganni1987: I just grew up backing stuff on DVDs, in a sort of way I've always trusted them more than a spinning drive. It's just the way I'm used to.
Funny. So have I; and that is why I only use HDs now. :-)
Maybe I should not have purchased the cheap CDs and DVDs.
avatar
ssokolow: Gowor said that some users have browsers that do header detection, resulting in the BIN files being opened as RARs.

In such a case, the simplest solution is to make the browser see it as an EXE instead using a dialog-displaying stub prepended to the file.
No it doesn't work like that, it's not the browser who will "execute" the file (unless it's an ActiveX component), it's Windows, and Windows won't execute it unless it has the correct extension. If you make the browser see it as an EXE then it will save to the disk as an EXE and not as a BIN.

I think you are mixing file headers with HTTP headers. The issue is that some browser (or even Windows explorer if you have installed some extraction tool) will detect that the file is a RAR by reading it's header and will offer the possibility to extract it.

One of the solution of course would be to alter the file in one way or another to prevent it from being identified as a RAR file. That would work but would have two disadvantages, first they would have to make sure that their "unrar" dll is still compatible with the "altered" format and it would also means that they would need a custom tool to add or remove file to an existing archive, or at least have some tool to convert the file back and forth between a real RAR and the "altered" version.
Post edited December 30, 2014 by Gersen
avatar
ssokolow: Gowor said that some users have browsers that do header detection, resulting in the BIN files being opened as RARs.

In such a case, the simplest solution is to make the browser see it as an EXE instead using a dialog-displaying stub prepended to the file.
avatar
Gersen: No it doesn't work like that, it's not the browser who will "execute" the file (unless it's an ActiveX component), it's Windows, and Windows won't execute it unless it has the correct extension. If you make the browser see it as an EXE then it will save to the disk as an EXE and not as a BIN.

I think you are mixing file headers with HTTP headers. The issue is that some browser (or even Windows explorer if you have installed some extraction tool) will detect that the file is a RAR by reading it's header and will offer the possibility to extract it.

One of the solution of course would be to alter the file in one way or another to prevent it from being identified as a RAR file. That would work but would have two disadvantages, first they would have to make sure that their "unrar" dll is still compatible with the "altered" format and it would also means that they would need a custom tool to add or remove file to an existing archive, or at least have some tool to convert the file back and forth between a real RAR and the "altered" version.
The whole point is to make sure users don't try to unpack it as a RAR. If the browser says its an EXE but the OS refuses to execute it because it lacks the EXE extension, mission accomplished.

unrar.dll will require no changes because it's the same mechanism used to implement self-extracting RAR archives.

As for the "altered format" part, I suggested that too as the next step along. It's trivially easy to add or remove the seven-byte identifying string from the beginning of a RAR file and, given that they apparently implemented the password calculation within their unrar.dll, it should also be easy for them to comment out the check for those seven bytes.

Hell, they could just replace them with their own GOG-specific RAR-identifying header and edit the bytestring that unrar.dll checks for.

Again, trivial on all counts. (Especially if their GOG-specific identifying string is the same length. They could open the file for random access and overwrite those bytes without having to make a copy.)

In fact, using a different identifying string of the same length is so trivial that, as long as you can get permission to do it, you can accomplish it by hex-editing the DLL directly. That sort of thing was a classic DOS-era trick people used to pseudo-secure their computers by doing things like changing the "DIR" command into "DUR".
Post edited December 30, 2014 by ssokolow
avatar
Ganni1987: I'm not sure which browser identifies the bin files as rar, can't say I've ever heard about this either.
I highly doubt any browser performs binary header checks. Browser relies either on MIME type information coming from the HTTP server (something that GOG controls) or on the extension (something that GOG controls as well and can set to anything they like, for example to .gogpackage or whatever).
avatar
Gede: Personally I will allow GOG a few days to review their standing on this issue, and will then act accordingly. I don't expect them to come out crying "Sorry guys! Our bad! We're dumping the work we did last month and starting anew, using only DEBs and APT." But I believe we should manifest ourselves and show how disapointed we feel right now.
Well Gowor said that he was open for suggestion so suggesting things is good, but personally, given the period of the year we are in, I wouldn't really expect anything before next week or the week after.