Timeline for Make your language unusable
Current License: CC BY-SA 3.0
35 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 19, 2017 at 15:53 | comment | added | Olivier Grégoire |
Well, since it was beaten, I can now add a link to my answer beating it. A better way to actually avoid this kind of workaround in this answer above is to replace System with java.lang.System. But even then, there are other ways to beat this ;)
|
|
| Jul 19, 2017 at 11:58 | comment | added | Kevin Cruijssen |
@OlivierGrégoire lol, I'm also working on it :) Btw, I think it should be possible to put in and out back the way it was by using reflection to enable it again, and create a FileDescriptor similar to the default one of Java's source-code.
|
|
| Jul 19, 2017 at 11:49 | comment | added | Olivier Grégoire | Shhht @KevinCruijssen! You're stealing my "robbers" ideas X( But I have more, no worries :p | |
| Jul 19, 2017 at 11:47 | comment | added | Kevin Cruijssen | @OlivierGrégoire Can be resolved by putting the code of DankMemes inside a static block though: Copy of code in TIO. | |
| Jul 19, 2017 at 11:41 | comment | added | Kevin Cruijssen | @OlivierGrégoire Works with Java 8 as well. Just tested it. | |
| Jul 19, 2017 at 9:03 | comment | added | Olivier Grégoire |
Snippet to replace // program here: } static { System.out.println("Hello World!"); } {. Works until Java 7 included. I think it doesn't with Java 8 anymore, but I'm not sure.
|
|
| Oct 1, 2016 at 11:19 | comment | added | Pierre Arlaud | @EriktheGolfer Naaah it's just more secure! | |
| Oct 1, 2016 at 6:34 | comment | added | Erik the Outgolfer | @PierreArlaud There is a simpler explanation: Java is almost always just too long to compete in a code-golf challenge, so I won't bother with it at all. | |
| Oct 22, 2015 at 15:57 | comment | added | DankMemes | @numeri You don't say? | |
| Oct 22, 2015 at 13:42 | comment | added | Numeri | Well, this definitely isn't golfing! :D | |
| Oct 22, 2015 at 12:45 | comment | added | Pierre Arlaud | @ceasedtoturncounterclockwis It's because java is more secure so it's harder to break :D | |
| Oct 21, 2015 at 22:59 | comment | added | DankMemes | @ceasedtoturncounterclockwis Welcome to Java on PPCG | |
| Oct 21, 2015 at 20:20 | comment | added | ceased to turn counterclockwis | Summary of this challenge so far: 1. JavaScript, 12 chars. 2. Emmental, 6 chars. 3. x86, 12 bytes. 4. Python, 42 chars. 5. Java, 2264 chars! Why am I not surprised? | |
| Oct 21, 2015 at 13:03 | history | edited | DankMemes | CC BY-SA 3.0 |
added 153 characters in body
|
| Oct 21, 2015 at 12:50 | comment | added | user45941 |
You should add public void checkExec(String cmd){throw new SecurityException("nope");} to your SecurityManager to prevent Runtime.exec.
|
|
| Oct 19, 2015 at 18:46 | comment | added | Jerry Jeremiah | +1 Personally I don't consider the /proc workarounds as real deal breakers because I don't use Linux and neither my Unix OS not my Windows OS has a /proc filesystem. | |
| Oct 19, 2015 at 7:19 | comment | added | Peter Taylor |
You'd also need to clobber Runtime.exec, because otherwise I can open a shell and script obtaining the ppid and using that to get at its fds 0 and 1. But I'm not sure whether it's worth bothering with trying to fix that until the question is improved, because IMO the best way of clarifying the inconsistencies would be to prohibit stdio-breaking approaches altogether.
|
|
| Oct 19, 2015 at 6:26 | comment | added | Peter Taylor |
Your fix is far too narrow. I just need to ungolf slightly to work around it, using File.getCanonicalPath() to resolve /proc/self and then building the paths from that.
|
|
| Oct 18, 2015 at 23:05 | comment | added | DankMemes | @Mego Well, earlier versions of Java were notorious for security bugs but in Java 8 the SecurityManager should be solid. | |
| Oct 18, 2015 at 23:04 | history | edited | DankMemes | CC BY-SA 3.0 |
added 68 characters in body
|
| Oct 18, 2015 at 23:03 | comment | added | DankMemes | @PeterTaylor fixed. | |
| Oct 18, 2015 at 23:03 | comment | added | user45941 |
You also need to add a check for "suppressAccessChecks" to disable using reflection to force the System SecurityManager field to null. But still, I'm pretty sure there's a way around it.
|
|
| Oct 18, 2015 at 23:03 | history | edited | DankMemes | CC BY-SA 3.0 |
Prevent opening /proc/self/fd/* on linux
|
| Oct 18, 2015 at 21:33 | comment | added | Peter Taylor |
I can still work around it, at least in Linux. Here's cat: FileInputStream in = new FileInputStream("/proc/self/fd/0"); FileOutputStream out = new FileOutputStream("/proc/self/fd/1"); int b; while ((b = in.read()) != -1) out.write(b); out.close(); in.close();
|
|
| Oct 18, 2015 at 20:59 | comment | added | DankMemes | @Mego Fixed, again | |
| Oct 18, 2015 at 20:58 | history | edited | DankMemes | CC BY-SA 3.0 |
more fixes
|
| Oct 18, 2015 at 20:16 | comment | added | DankMemes | @VTCAKAVSMoACE I considered that but it requires the code to use Integer.valueOf or something; primitive integer operations still work. | |
| Oct 18, 2015 at 17:52 | comment | added | user45941 |
It'd be insanely difficult to prevent any sort of operation that would output a 1 or a 2. Even Test2.class.getMethods().length would do the trick.
|
|
| Oct 18, 2015 at 17:39 | comment | added | Addison Crump | Maybe even playing with the integer cache to make math useless might be worth investigating. c: | |
| Oct 18, 2015 at 17:10 | comment | added | user45941 | Playing with reflection is almost always reversible. | |
| Oct 18, 2015 at 16:00 | history | edited | DankMemes | CC BY-SA 3.0 |
added 276 characters in body
|
| Oct 18, 2015 at 15:52 | comment | added | DankMemes | Fixed @Mego | |
| Oct 18, 2015 at 15:52 | history | edited | DankMemes | CC BY-SA 3.0 |
Fixed problems
|
| Oct 18, 2015 at 15:42 | comment | added | user45941 | Negative. | |
| Oct 18, 2015 at 15:21 | history | answered | DankMemes | CC BY-SA 3.0 |