Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Document our security limitations #845

Merged
merged 5 commits into from Mar 25, 2014
Merged

Document our security limitations #845

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
68bba2d
Limitations
public Mar 22, 2014
1977a60
Rephrase to keep the spell checker happy
public Mar 22, 2014
da4e0fa
Add citation for being a low risk issue
public Mar 24, 2014
cfe1c0b
Rephrase to avoid american english failure
public Mar 24, 2014
a108ac6
"potentially vulnerable"
public Mar 25, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
1 change: 1 addition & 0 deletions docs/index.rst
View file
Open in desktop
Expand Up @@ -85,6 +85,7 @@ The ``cryptography`` open source project
installation
development/index
security
limitations
api-stability
doing-a-release
changelog
Expand Down
19 changes: 19 additions & 0 deletions docs/limitations.rst
View file
Open in desktop
@@ -0,0 +1,19 @@
Known security limitations
--------------------------

Lack of secure memory wiping
============================

`Memory wiping`_ is used to protect secret data or key material from attackers
with access to uninitialized memory. This can be either because the attacker
has some kind of local user access or because of how other software uses
uninitialized memory.

Python exposes no API for us to implement this reliably and as such almost all
software in Python is potentially vulnerable to this attack. However the
`CERT secure coding guidelines`_ consider this issue as "low severity,
unlikely, expensive to repair" and we do not consider this a high risk for most
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking at this point, but should it just say users instead of most users?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could be a risk for some users?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "most users" is fine. Hey, unlikely as it may be there might be some use-cases where this is a potential high risk issue.

users.

.. _`Memory wiping`: http://blogs.msdn.com/b/oldnewthing/archive/2013/05/29/10421912.aspx
.. _`CERT secure coding guidelines`: https://www.securecoding.cert.org/confluence/display/seccode/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources