change the notification modal to accept the primary message and an
Option of independent text to display as a qrcode
pub fn show_notification(&self, notification: &str, qrtext:Option<&str>) -> Result<(), xous::Error> {}
Instead of having a single, shared buffer, simply stack-allocate the log
buffers.
This paves the way in the future to allow for buffers that are
larger-sized and span multiple pages. But most importantly it alleviates
inter-thread locking and contention when passing messages.
Signed-off-by: Sean Cross <sean@xobs.io>
Previously, we would reject buffers that were the maximum allowed size.
This is reported in #141.
Allow these maximally-sized buffers to be printed, since they don't end
up causing a problem.
Signed-off-by: Sean Cross <sean@xobs.io>
- track field heights using the drawing height directly
- use an &mut reference in the text processing section so changes stick
- other minor cosmetic improvements
Probably nobody is really using secret Bases right now, but it's
probably a good idea to lay out all the infrastructure and start
testing it for when it comes time to do it with data that really
matters.
Previous version was v0.0.1.1
New version is v0.0.2.1 (don't ask me why I skipped v0.0.2.0)
The most significant change is that the key derivation for the basis
is now split into two keys. One key is used for the page table ECB
encoding, and a different key is used for the data AES-GCM-SIV encoding.
This is because someone much smarter than me looked at my scheme
and said it is very dangerous to use the same key for two different
types of ciphers. This person is correct, so it had to be rectified.
For the System Basis, the keys are encrypted using the root keys
wrapper API. In this case, we simply create two random keys, one for
the page table, and one for the data region, and wrap them using
the root keys API.
For user secret Basis, the derived keys are sent through HKDF
with two different "info" strings to derive a pair of keys from
a common password.
In case the cryptographer who looked at this is reading along,
note that the basis name is encoded as a fixed-length, 0-padded
record, so, we don't encode the length of the basis in the hash
used to derive the keys. When I explained the scheme I thought
I was using a variable-length basis name to derive the key, but
when I checked the code, it's always 64 bytes long, and bytes
that are not used are 0-padded, so, I think we don't need the
length encoding field.
This is basically the Rust example for the web server, with
some tweaks. Add a command to make the device buzz when
a particular URL is hit, and to wait before responding when
another one is hit.
total threads in the net crate are around 10 right now, 32 max, so
increasing the sleeping thread limit to 16, since every now and then
we get exhaustion notes.
- allow for zero-length tx/rx returns
- implement "shutdown" function, which is different from close:
shutdown requires any pending connections to return Ok(0) immediately,
but the socket is not dropped.
