| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
| |
Also handle partial writes in alloc_mmap
|
| | |
|
| |
|
|
|
|
|
| |
Add a push_back that takes a single argument ala std::vector
For appending, provide some namespace level += operators - we can use
this technique with either MemoryRegion or a std::vector.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the initial/default length of the array, update all users to instead
pass the value to the constructor.
This is a old vestigal thing from a class (SecureBuffer) that used
this compile-time constant in order to store the values in an
array. However this was changed way back in 2002 to use the same
allocator hooks as the rest of the containers, so the only advantage
to using the length field was that the initial length was set and
didn't have to be set in the constructor which was midly convenient.
However this directly conflicts with the desire to be able to
(eventually) use std::vector with a custom allocator, since of course
vector doesn't support this.
Fortunately almost all of the uses are in classes which have only a
single constructor, so there is little to no duplication by instead
initializing the size in the constructor.
|
| |
|
|
|
|
| |
Avoid using using directives in MemoryVector and SecureVector to bring
things into scope; it brings them into public scope even if they are
protected which is not desirable. Instead disambiguate using this->func()
|
| | |
|
| |
|
|
| |
MemoryRegions and concatenated them.
|
| |
|
|
|
|
|
|
|
|
|
| |
Add RandomNumberGenerator::random_vec, which takes an length n and
returns a new SecureVector with randomized contents of that size. This
nicely covers most of the cases where randomize was being called on a
vector, and is a little cleaner in the code as well, instead of
vec.resize(length);
rng.randomize(&vec[0], vec.size());
we just write
vec = rng.random_vec(length);
|
| |
|
|
|
| |
representation (rather than in an interator context), instead use &buf[0],
which works for both MemoryRegion and std::vector
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
harmonising MemoryRegion with std::vector:
The MemoryRegion::clear() function would zeroise the buffer, but keep
the memory allocated and the size unchanged. This is very different
from STL's clear(), which is basically the equivalent to what is
called destroy() in MemoryRegion. So to be able to replace MemoryRegion
with a std::vector, we have to rename destroy() to clear() and we have
to expose the current functionality of clear() in some other way, since
vector doesn't support this operation. Do so by adding a global function
named zeroise() which takes a MemoryRegion which is zeroed. Remove clear()
to ensure all callers are updated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
container like vector, truncate is simply resize, but what
MemoryRegion called resize will zap the entire contents, and then what
was resize was called grow_to. This is really problematic in terms of
the goal of replacing MemoryRegion with a vector with a custom
allocator.
In this checkin:
- Remove MemoryRegion::grow_to and MemoryRegion::truncate
- Change the semantics of MemoryRegion::resize to change the size
while keeping any current contents intact (up to the new size),
zero initializing any new values.
Unrelated, just noticed the lack while I was in there, add a version
of CryptoBox::decrypt taking a std::string for the input.
|
| |
|
|
| |
Required by the hex decoder.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
depending on if INITIAL_LEN is non-zero. Normal semantics are the
vector will change size based on whatever it is constructed with,
but that's bad in cases like
SecureVector<byte, 4> val(buffer, 3);
which in the past would be a 4 valued thing with 3 elements set
and one zero trailing. (This construct showed up in base64 and
possibly elsewhere). If INITIAL_LEN is set, use copy instead so
the length does not change.
C++0x cannot come soon enough.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
that enable botan to be built under the clang C++ compiler.
|
| |
|
|
| |
to meaning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a second template param to SecureVector which specifies the initial
length.
Change all callers to be SecureVector instead of SecureBuffer.
This can go away in C++0x, once compilers implement N2712 ("Non-static
data member initializers"), and we can just write code as
SecureVector<byte> P{18};
instead
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pointer was actually set. Otherwise, the following problem could occur
if an allocator could not be found:
init() will call Allocator::get, which throws an exception
init() is called from the constructor of the subclasses (MemoryVector, etc)
Since the constructor of MemoryRegion has already finished, its destructor
will be called.
~MemoryRegion will call deallocate()
deallocate() will then access a NULL pointer
By guarding the call, the exception is propagated correctly.
|
| |
|
|
|
|
|
|
| |
containers (specifically vector).
Rename is_empty to empty
Remove has_items
Rename create to resize
|
| | |
|
| |
|
