deltaengineering asked: What do you think is the most important aspect of a visual novel engine?
Aside from the obvious technical aspects (platforms, performance, neat effects), I think it’s important to have a degree of UX in its usage from a developer, mainly writer, standpoint.
This goes deeper than ‘simply’ having an easy-to-write scripting format for pure dialogue: I also feel that the engine shouldn’t surprise you in a more complex way, and that as an engine developer you have to actively work (with regular testing) to improve that.
From a coder perspective, you should have APIs that make it immediately obvious what’s going on, and only do what they seem to do; you want to have layered APIs that allow you to dive into the engine internals deeper for each layer at leisure; you want to be backwards-compatible to a degree, but not to the degree you have years of legacy cruft that maybe should have never been designed in your engine code and API.
From a writer perspective, aside from an easy scripting format for simple things, you don’t want the engine yelling at you for a detail that you as a writer shouldn’t even care about like mixing tabs with spaces, or something similar. You don’t want to have to deal with things like load order or function or variable scopes as a writer: you want to just open something in your text editor, write away, and have it work. This would ideally be analogues to the “highest” level of the engine-given APIs: very simple commands that literally a monkey could use without running into troubles.
I feel like this is something where existing engines might fall short, and hell, maybe rave will too, but damned if I don’t try to make it as good as I can in that aspect.
deltaengineering asked: How did you suddenly get the idea to add an ask feature?
I figured that some people might want want to know neat details about stuff I do or ask other random things. Some friends seem to have good success with their ask features, so I figured I might give it a shot.
Recently, I purchased my own domain for personal use and as file/project dump. Being a good security-conscious netizen, I immediately turned to StartSSL to get some fresh TLS certificates for this domain, so people wouldn’t receive those pesky self-signed security errors when attempting to browse my pages.
Seeing as I usually generate a seperate certificate key per domain, it was time to create a new one. Because I don’t really want to change certificate domain keys a lot, I decided to make this one future-proof by generating a 8192-bit RSA keypair for use in the certificate. All was well: my keys were accepted and certificates were generated by StartSSL just fine, the site seemed to work just fine in Firefox on OS X (my own setup) and in a few friends’ various browsers on other operating systems as well.
That is, until a few days later someone started complaining about receiving the following error on Chromium:
The same issue turned out to be present in Chrome, Safari and basically every browser that used OS X’s native crypto stack as well. Seeing as the given error messages were less than ideal (Safari just pretended I didn’t actually want to load a page), I decided to investigate by starting Chromium in debug log mode:
An unknown error. Wonderful. At least we have the native error code, as emitted by Security.framework. After doing some digging around I found the appropriate error message that belongs to error code -2147409643, or perhaps better expressed in its unsigned form as 74005:
Still not very informative. After this unsuccessful endeavour, I tried importing the key into my system keychain and see what happened: it gave me, again, a rather cryptic error code of -67762. Luckily, searching for that code on Google led me to a certain StackOverflow question:
Security update 2006-007 apparently broke 8192-bit certificates on OS X and no one bothered to fix it (https://discussions.apple.com/message/3650856#3650856). However there is (or rather used to be) a solution for this bug (or feature?) and it is in https://discussions.apple.com/thread/2668985 You’ve just got to execute sudo defaults write /Library/Preferences/com.apple.crypto RSAMaxKeySize -int 8192 in a Terminal prompt.
Sadly, like the question states, this does not work in Mavericks and upwards. This is because when Apple upgraded libsecurity_apple_csp, the library that takes care of the basic crypto services for Security.framework, from r55003 to r55471 for Mavericks, they also changed the location where the preference should be written to. Let’s take a look in /lib/RSA_DSA_keys.h:
/* Those max RSA sizes can be overridden with these system preferences */ #define kRSAKeySizePrefsDomain "com.apple.security"
A-ha! We have to write to /Library/Preferences/com.apple.security now! Simply changing the file target in the aforementioned command gives us the desired result:
To be fully future proof and to (hopefully) never have to deal with this again, I set the maximum key size to 32768 bits:
Now, of course, the obvious question is: why? Why would you artificially limit RSA key sizes? Admittedly fairly clueless on the subject, I decided to ask my good friend Aaron Jones:
<@Shiz> Hey, Aaron. Are there any real reasons for artificially limiting the maximum RSA key size a crypto library can process? <&Aaron> Shiz: mitigate denial of service? it does get exponentially harder for the higher security levels
(to clarify, with ‘exponentially’ he means non-linearly, not exponential growth.)
This seems to be backed by a post on StackOverflow and the general maths behind RSA. According to RSA’s own FAQ, on page 75, “public key operations take O(k^2) steps, private key operations take O(k^3) steps, and key generation takes O(k^4) steps”, in a regular implementation, with k being the key size.
Indeed, Mozilla, up until last year, used to restrict the Diffie-Hellman key size to 2236 bits in the crypto library used by Firefox, NSS, in a similar fashion and for similar reasons. There’s a reason people say TLS takes a heavier load on the server, and it definitely makes it more susceptible to denial-of-service attacks.
However, as hardware gets faster and more efficient, we should also take care in keeping those maximum key sizes sensible for modern uses: seeing as the 2006-007 update instated the maximum key size in RSA initially, I’d say it’s about time for an update and would like to implore Apple to explore the options it has: 8192+ bit RSA keys are getting increasingly (if even slightly) common, and they will only start appearing more over the following years. Especially since, you know, a lot of users are on a desktop and needn’t fear getting (D)DoS’d over TLS any time soon.
Special thanks go to @duane_moody for figuring out that the newest version of libsecurity_apple_csp lives in the Security project instead of being its own project like it was before on the Apple Open Source repository. Thanks to /u/pigeon768 for pointing out a mistake in Aaron’s quote.
‘Tap’ Homebrew’s system duplicates repository. This repository contains packages that are normally already supplied by OS X, but which you might want to update for one reason or another. In this case I wanted ECDSA support, something that is not provided by OS X’s native OpenSSL. brew tap homebrew/dupes
Install Homebrew’s OpenSSL. This by default will not place anything in /usr/local because of possible system OpenSSL conflicts. brew install openssl
Install Homebrew’s OpenSSH, with Homebrew’s OpenSSL in mind. You can also make it support Apple’s system keychain by adding the --with-keychain-support option. brew install openssh --with-brewed-openssl --with-keychain-support
And you’re done! Reopen a terminal session and you’re good to go. If you want to compile more applications with your brand-spanking-new OpenSSL, you might find it easier to force linking it to /usr/local using brew link --force openssl. Keep in mind that this may cause system conflicts, and just adding -I /usr/local/Cellar/openssl/$VERSION/include and -L /usr/local/Cellar/openssl/$VERSION/lib to your CFLAGS and LDFLAGS is usually a better method.
If you want to run the OpenSSH (server-side) daemon as well, you need to edit /System/Library/LaunchDaemons/sshd.plist to point to the new binary in /usr/local/bin and reload the plist. Sadly, since /usr/libexec/sshd-keygen-wrapper takes a path to sshd but doesn’t actually use it, you need to update it as well to point to the new sshd and ssh-keygen binary locations.
