Bug - Fixed Can't load files with .ash extensions

B

bordemstirs

Member
Working on a rather tedious proof of concept script that has to file_to_map itself, and I was getting an Unexpected Error. I thought maybe I wasn't allowed to load files from non-/data directories (though I thought at one time I was) so I moved a copy into /data. Same error. After a bunch of toying around and using a very simple script (just file_to_map) and a very simple data file (2 lines) I was able to narrow down the issue: whenever the file I'm requesting has a .ash extension I get a debug log, even if the file doesn't exist (however a non-existing .txt file works just fine). Even using the same file and just changing the name would get the error (or lack thereof, when the extension is not ash.)

Code: 
Unexpected error, debug log printed.
class java.lang.NullPointerException: null
java.lang.NullPointerException
	at net.sourceforge.kolmafia.textui.DataFileCache.getBytes(DataFileCache.java:166)
	at net.sourceforge.kolmafia.textui.DataFileCache.getReader(DataFileCache.java:158)
	at net.sourceforge.kolmafia.textui.RuntimeLibrary.file_to_map(RuntimeLibrary.java:4917)
	at net.sourceforge.kolmafia.textui.RuntimeLibrary.file_to_map(RuntimeLibrary.java:4908)
	at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at net.sourceforge.kolmafia.textui.parsetree.LibraryFunction.execute(LibraryFunction.java:115)
...
 
Somewhere around here is a thread that explains why it is a security flaw to allow .ash files to be manipulated by mafia. Maybe you can find it if you want more information. It was after that discussion that the ability was purposefully removed.

It shouldn't give a debug log though. Perhaps that is a bug? I closed the thread as not a bug because its disability is by intent. Someone else can open it if they want to figure out why you got a debug log.
 
Last edited:
Well thank you Bale!
Funny, I think I found the thread you were talking about and I actually posted in it!
Change must have been after I stopped following that thread.

Anyway, while I can (sorta, not really, but I work with what I can) understand the not-manipulating-ASH rule, that would mean no map_to_file()... what harm can come from file_to_map()?
 
bordemstirs said:
Anyway, while I can (sorta, not really, but I work with what I can) understand the not-manipulating-ASH rule, that would mean no map_to_file()... what harm can come from file_to_map()?
Click to expand...

Overwriting/hijacking a popular script such as ZLib, for example. More info also in this thread.

Edit: Oops, I misread. Security issues in mapping an ash file to a map? I can't particularly think of any at the moment. Also what you're getting is an unhandled exception, whereas all the exceptions we've talked about are handled in some way or another, so yeah perhaps what you are seeing is something else.

Edit 2: Mmm I think you're seeing something else. I can't look at it right now but, as a work-around, name your file "myfile.ash~" with the ~ at the end, KoLmafia will still treat it like a normal ASH file (it will just be hidden from the menus), but you should be able to use file_to_map() with it too.
 
Last edited:
11539 breaks loading a map via URL

At the risk of the information here being buried, I figure it would be best to open up a bug report for this one.

Patch in the SVN changes thread reverts some of Holatuwol's changes, but perhaps there was something else in mind that he wanted to achieve.
 
11550 re-enables using a URL with file_to_map(). It's basically the same as that patch but with the code arranged differently.
 
lostcalpolydude said:
11550 re-enables using a URL with file_to_map(). It's basically the same as that patch but with the code arranged differently.
Click to expand...

Thanks, I did the other patch in a rush anyway :)

One thing to note, as far as I could tell, the old code would return false if you tried to map_to_file() an http address, that behaviour should probably be restored, right? I did that in the patch posted in the other thread. I'm pretty busy though, I only checked the diff. I think from memory, if the file handle returns null it'll return false anyway, but I thought it was better to just exit the code before that if we knew it was an http address.
 
The end result is returning false both ways. I thought it made sense for getFile() to return null in general if it's a URL (for uses that don't currently exist, and may never exist), and from there it makes sense to not repeat the logic in printBytes().
 
lostcalpolydude said:
I thought it made sense for getFile() to return null in general if it's a URL (for uses that don't currently exist, and may never exist), and from there it makes sense to not repeat the logic in printBytes().
Click to expand...

That is probably closer to what Holatuwol was intending to happen :)
 
You must log in or register to reply here.
Back
Top