| 12345678910111213141516171819202122232425 |
- <HTML>
- <HEAD>
- <TITLE>David Piuva's Software Renderer</TITLE>
- </HEAD>
- <BODY>
- <link rel="stylesheet" type="text/css" href="PageStyle.css">
- <A href="../Manual.html">Back to main page</A>
- <P> <b>Security information for David Forsgren Piuva's Software Renderer</b>
- <P> <IMG SRC="Images/Border.png">
- <P> <B>Purpose</B>
- <P> The library is designed to stand the test of time when making software to be ported by future generations.
- Any attempts at security against hackers from a distant future with hundreds of years to study the source code and superior quantum processors to break your encryptions would be futile.
- <P> <IMG SRC="Images/Border.png">
- <P> <B>Design</B>
- <P> Due to the flat design of the library (shallow call depth), applying browser grade security in every internal function would not be practical nor fast.
- Memory bound checks are removed in release builds for maximum performance.
- Your application should terminate if incorrect input caused an error to be thrown from the library, because resuming execution from a state which breaks the invariant means that correctness can no longer be guaranteed.
- <P> <IMG SRC="Images/Border.png">
- <P> <B>How to be "safe" (if such a thing can ever be acheived)</B>
- <P> In order to be safe, you must either read all input from a reliable source (like a protected folder) or validate all input yourself before giving it to the library (no memory aliasing, extreme image dimensions, invalid file syntax...).
- Just preventing others from writing over binaries would not help, because the library does not have security against file corruption when loading media.
- Treat it like you would treat a fast low-level graphics API, don't give direct access to potential attackers.
- <P> <IMG SRC="Images/Border.png">
- </BODY>
- </HTML>
|
