pouët.net

Digitally signing kkrunchy compressed releases

category: code [glöplog]
Quote:
Although, I'd like to see the inner workings of several demos, the amount of effects, code, textures and music rip offs would increase dramatically.


2004 called, they want their ".werkkzeug is going to kill the scene" argument back.
added on the 2015-04-24 12:25:12 by gasman gasman
Quote:
2004 called, they want their ".werkkzeug is going to kill the scene" argument back.
Oh, so this must be reason why the scene is dead.
.werkkzeug killed it!
added on the 2015-04-24 13:12:57 by introspec introspec
.werkkzeug killed the scene in 1986!
LOL, I first read digitally singing.
added on the 2015-04-24 14:21:14 by blueghost blueghost
Quote:
BoyC, as I see it, instead of public open access, have scene.org (or some other) host the service and let only access to verified party organizers or something (maybe special party-sceneid verified accounts)... then include the need of an unpacked exe in the party-rules for compo entering (this could be a well-defined zip format or something where an automatic tool could be made).

I'm not sure party organizers need or would like any more work thrown their way. I can imagine this as an opt-in service where those running the service can decide who to give access to for a limited time, probably based on previous releases and current activity.

Quote:
And if you check the comments, some newfaggot flagged conspiracy.hu as possible malicious domain because some snake oil company blacklisted them for no reason.
"ORDER WEB SITE CLEANUP AND BLACKLISTING REMOVAL!"

Oh FFS. And it had to be Yandex. The irony.
added on the 2015-04-24 16:36:43 by BoyC BoyC
Quote:
I'm not sure party organizers need or would like any more work thrown their way. I can imagine this as an opt-in service where those running the service can decide who to give access to for a limited time, probably based on previous releases and current activity.

That's why I said: if there's a standarized format for releases that want to be signed (in the zip, for example, make a "myintro_unkkrunched.exe", or maybe some config file with a defined format which says which exe's should be signed and the txt files to include in the release archive) this could be done pretty much automatically for party organizers... just have a tool that "rezips" for distribution... ether rule or config based.

And if the entrants fail to include that config file, then skip the signing alltogether. It's on best interest of release creators that their files are signed, so having a bit of shared effort could work (party organizers running the tool, and intro creators making that config file and structuring the zip file in a defined way).

The party-distribution-tool should be rather easy to do once the format is defined

Of course, this wouldn't have to be the only way to access that service, but I don't think it would be a hassle for anyone (neither party organizers nor intro creators). If anything, having a certificate sign-tool by scene.org would be the most significant hassle, since everything having to do with certificate authorities and digital signing tend to be picky on security and vulnerabilities... but if digitally signing is the way to go for this, then this is a rather affordable option.
added on the 2015-04-24 18:43:17 by Jcl Jcl
I see all that config file tweakery you're suggesting as a serious point of possible failure, and completely unnecessary. What would work a lot better is that scene.org (let's say they run the service) says "oh, xy is making an intro for the party, they can have access to the service from the beginning to the party until the beginning of the competition to sign their releases".

This approach would
*skip all the extra steps needed with what you're saying
*not force groups to release uncompressed executables into the wild
*let groups check if a release actually fits the size limitation and runs before submitting a prod (kkrunchy still produces crashing executables sometimes)
*keep everything the way it is from the PoV of the organizers, and not burden them with _any_ extra effort
added on the 2015-04-24 19:09:07 by BoyC BoyC
i think the (not immediate) future of the 64k intro scene is the web anyways. secure by definition, easy outreach. we'll sooner or later have to forget about binary executables. plus nobody out there cares if an intro that is a piece of magic takes 64k or more - it's still magic if it's 200k. i think WebGL 3.0 will be inflection point.

in the meanwhile... intros are only for introsceners and demosceners, so i am fine with having to rename .exe files to .txt, or whatever ugly trick it takes me to watch the intros. not that this helps to the discussion though.
added on the 2015-04-24 19:24:49 by iq iq
Quote:
i think the (not immediate) future of the 64k intro scene is the web anyways. secure by definition

I can just imagine you laughing hysterically while writing that.
added on the 2015-04-24 19:57:02 by Gargaj Gargaj
lol. well, in fact i sort of believe it. i don't like it, but i believe that's the future. on the security bit, i don't know enough about web, but it seems people trust the browsers' sandboxes for now?
added on the 2015-04-24 20:05:53 by iq iq
The automatic service, the way jcl described minus the config stuff, is a really good idea that may work, it can also be connected with sceneid, accounts approved by someone responsible for the service and give access to them to perform auto packing and signing so the service can be around all time of the year and not just on demoparty dates and without permission per executable.
added on the 2015-04-24 20:07:47 by Defiance Defiance
Quote:
on the security bit, i don't know enough about web, but it seems people trust the browsers' sandboxes for now?

Yeah they do.
added on the 2015-04-24 20:14:33 by Gargaj Gargaj
Defiance: yeah that's what I'm saying as well, and if security paranoia is an issue it'd be still possible to limit access to party dates or to request limited time access. The idea of checking executables before packing and signing is the key. It could just about work.
added on the 2015-04-24 20:18:09 by BoyC BoyC
The only issue with that would be that kkrunchy should be ported into linux and be run be a python or php script from there if it is to be hosted on scene.org. also is there a sign tool for linux?
added on the 2015-04-24 21:00:08 by Defiance Defiance
yeah google's my friend... there a framework (with a sign tool) and is called mono.
added on the 2015-04-24 21:26:36 by Defiance Defiance
Quote:
lol. well, in fact i sort of believe it. i don't like it, but i believe that's the future

The future? Impress the audience of a PC demo compo with 10 year old technolgy? Sure, WebGL demos can impress based on their art style and direction, but not based on their tech.

Unless WebGL catches up with the modern GPU architecture, it will remain a lesser platform. I don't see that in a near future WebGL will compete with modern PC OS as equal platforms in this sense. (and don't quote turing completeness here...)

Wasn't making demos about making the best out of state of the art hardware?

Quote:
not that this helps to the discussion though.


Agreed. Sorry for derailing the topic.
added on the 2015-04-24 22:19:41 by xTr1m xTr1m
Quote:
The only issue with that would be that kkrunchy should be ported into linux

I'm not too familiar with porting stuff, but it shouldn't be that hard, it's a fairly independent piece of code. Could be that all that needs to be done is to set up a build environment for it.
added on the 2015-04-24 23:16:05 by BoyC BoyC
that "automatic signing" thing is a pretty naive idea. how long do you think it will take until someone takes the opportunity to push some malware this way?

Quote:
Wasn't making demos about making the best out of state of the art hardware?

not quite. its about making the best out of whatever arbitrary restrictions apply.
added on the 2015-04-24 23:31:13 by groepaz groepaz
iq: nice trolling attempt. or is it just paint thinner overuse? o_O

back to topic: a signing service (e.g., on scene.org or similar) should still require some sort of restricted access/authentification, just restricting the time isn´t enough if the date can be figured out that easily.
maybe manual unlocking of uploaded stuff is way to go - thus the service/certificate isn´t shared publicly since each executable is checked by a single party. There might not be a signed executable right a thecompetition, but a few hours afterwards should still do well.
added on the 2015-04-24 23:38:21 by T$ T$
groepaz: the idea would be to check uploaded files with some service like virustotal, and only compress+sign them server side if they are completely clean. Since the uncompressed executable would be available to the service we could even implement our own arbitrary checks (checking to see if the exe uses any of the major gfx apis would be an obvious candidate for example)

T$: obviously it would need to be controlled with other factors besides time limitation. Give access only to those SceneIDs that belong to people actually compiling the productions, limit to people who already have released, I'm sure we could come up with reasonable access limitations.
added on the 2015-04-24 23:55:34 by BoyC BoyC
Quote:
The only issue with that would be that kkrunchy should be ported into linux and be run be a python or php script from there if it is to be hosted on scene.org. also is there a sign tool for linux?

Hosting a windows server shouldn't be that hard either... I haven't really researched elegibility, but last time I checked, there was free Win 8.1 licenses for non-profit. As long as you are not doing Active Directory or any winserver-specific role, hosting a barebones Win 8.1 virtual machine with Apache or IIS should be just fine, and could run kkrunchy (and the microsoft sign tool) without any modifications.

There might also be Windows Server Core licenses for free for nonprofit (again, I haven't checked, but Microsoft is pretty keen on giving out licenses so I wouldn't be surprised), which takes very little hardware resources to run.

Not sure if scene.org would be wanting to host a windows box, but it's definitely doable.
added on the 2015-04-25 10:19:45 by Jcl Jcl
This idea only works at all, if all antivirus assume any signed binary does not need to be scanned. I'm pretty sure that is not the case.

In the antivirus industry (e.g. virus reverse-engineers sending samples to each other), the standard way of sharing detectable files is just to compress them with a simple preshared password. e.g. posting .zip with password "scene.org" should be fine.
added on the 2015-04-25 10:57:16 by shuffle2 shuffle2
(Of course it's then up to user to decompress in a way which won't cause the binary to immediately be removed, but IMO this is still the best way)

p.s. fuck AV :D
added on the 2015-04-25 11:01:41 by shuffle2 shuffle2
You cannot trust an executable signed by a centralized organization/community for many reasons. You can even find some malwares signed by m$. And this is not a trick or a hax or anything else, this is just the malware dev asking for m$ to sign their shit.
Each group could sign their own executable like you sign your mails with PGP for example. But it will not fix the false-positive issue.
Conclusion: "what las said"
Quote:

False positives happen all the time (not only with virus scanners) and if people fail to understand that - it's not your fault and you shouldn't care about it too much (sometimes not too easy, I know).
added on the 2015-04-25 11:24:30 by stfsux stfsux
zoom: or maybe 'conspiracy' raises more suspicion than 'mercury'??
BB Image
added on the 2015-04-25 13:41:49 by maali maali

login