Logs

<oneiric_> 0. greets
<oneiric_> hi
<Corklander> Hey!
<endogenic> o/
<oneiric_> 1. Project infrastructure / DevOps
<kinghat> hi all
<oneiric_> recently setup CircleCI, Docker and Bitbucket CI pipelines
<oneiric_> going to try out Drone CI (integrates w/ GitLab), and decide on a final CI provider
<oneiric_> will keep alternative configs in contrib/
<oneiric_> got a basic Docker image setup with everything needed to build tini2p
<oneiric_> need to fix net tests to be able to run in a container for accurate coverage stats
<oneiric_> other than that, CI is more-or-less setup
<oneiric_> will be experimenting/playing with gitea over the next weeks, and mirror GitLab to GitHub, BitBucket, and gitea
<oneiric_> unfortunately lost access to tini2p account on GitHub, though still have push ability
<oneiric_> main github repo is now: https://github.com/tnii2p-project/tini2p
<Corklander> 404 :(
<oneiric_> derp
<oneiric_> type
<oneiric_> typo
<oneiric_> my fingers are terrible today
<oneiric_> https://github.com/tini2p-project/tini2p
<Corklander> Yea!
<oneiric_> -_-
<oneiric_> lol
<oneiric_> anyway
<oneiric_> any questions/comments? i think that's all for infrastructure stuff.
<Corklander> Do you see any dependency problems with Drone CI or the other choices? (I haven't used them so I'm not sure about any restrictions/costs.)
<oneiric_> most of them i've seen are basically the same
<oneiric_> x free hours for builds, then monery
<oneiric_> the integrations are the differentiators
<oneiric_> circle works with github and bitbucket, drone works with gitlab
<Corklander> sry, have to go due to emrf, bbl
<oneiric_> think there are webhook integrations on most/all major gitserver providers
<oneiric_> anyway
<oneiric_> ttyl
<oneiric_> anything else on 1?
<oneiric_> 2. Current project status / what's been done
<oneiric_> spent a lot of time replacing crypto++ with libsodium + tiny-AES-c
<oneiric_> then realized, "oh, i need an SSL lib"
<oneiric_> so, added LibreSSL as a dependency for potential future Keccak patch, and replaced tiny-AES-c with SSL impl
<oneiric_> that's in an open MR: https://gitlab.com/tini2p/tini2p/merge_requests/2
<oneiric_> finished with code cleanup, generic crypto/signature wrappers, and a basic experimental ECIES-X25519-AEAD-Ratchet impl
<oneiric_> merged MR: https://gitlab.com/tini2p/tini2p/merge_requests/1
<oneiric_> currently working on generic wrappers for the proposed Blake2b EdDSA variants
<oneiric_> which i will discuss in 4
<oneiric_> questions/comments on 2?
<endogenic> awesome progress
<oneiric_> will also hopefully be able to help zzz with ECIES testing (fingers-crossed)
<oneiric_> thanks endogenic :)
<oneiric_> 3. Short-term road map
<oneiric_> implement the Blake2b sig variants to help other I2P projects with testing
<oneiric_> implement tunnels + basic netdb
<oneiric_> if lmdb interface is simple enough, will skip past doing blockfile format, and just use lmdb for addressbook/netdb needs
<oneiric_> that's where i want to be anyway :)
<oneiric_> adding alpha and beta milestones to the gitlab project
<oneiric_> projected alpha release for 2019/07/10
<oneiric_> with a beta following 3 months after
<oneiric_> will see how this first cycle goes, but will try to keep to that release schedule, or shorten it if feasible
<endogenic> good plan
<endogenic> the minimum usable set is generally critical to keep in mind to avoid getting lost along the way
<endogenic> dont think that's a huge issue here given the name "tiny" though :)
<endogenic> good origins
<oneiric_> yeah, if shorter, may do alpha (2 months) -> beta (2 months) -> point release
<oneiric_> true, as part of 4. i'll talk about the current sig variant proposals, and which of those will end up in tini2p
<oneiric_> which is actually a nice transition (smooth endogenic)
<oneiric_> 4. I2P proposal implementation
<oneiric_> https://geti2p.net/spec/proposals/123-new-netdb-entries
<oneiric_> https://geti2p.net/spec/proposals/144-ecies-x25519-aead-ratchet
<oneiric_> https://geti2p.net/spec/proposals/146-red25519
<oneiric_> https://geti2p.net/spec/proposals/148-eddsa-blake2b-ed25519
<oneiric_> we went over 123 and 144 last meeting, iirc
<oneiric_> one thing that has changed, zzz has said he will be switching focus back to ECIES, and hammering out some spec details
<oneiric_> so we are getting closer to a finalized spec, which will reduce code footprint
<oneiric_> 146 and 148 are the new sig variant proposals
<oneiric_> for eddsa
<oneiric_> RedDSA is needed for blinding encrypted lease sets, and Blake2b variants are needed to protect against LEA attacks
<oneiric_> Ed25519ctx was also suggested, and is being considered for LEA protection
<oneiric_> personally, think Ed25519ctx is gross given the alternatives, but it's in an RFC
<oneiric_> RFC 8032 to be specific
<oneiric_> the hash function in RFC 8032 isn't specified, other than being a crypto-secure hashing function with 512-bits security
<oneiric_> Blake2b satifies all criteria
<oneiric_> for full details see the proposals and #ls2 meeting logs
<oneiric_> so, my plan is to write generic wrappers for all variants, then keep whichever get accepted
<oneiric_> right now, it's looking like RedDSA-Blake2b-EdDSA can be used for all places where a signature is needed
<oneiric_> a lot is still up in the air though, and nothing has been finalized yet
<oneiric_> any comments/questions on 4?
<oneiric_> one more thing actually, EdDSA-Blake2b-Ed25519 could also be used everywhere a signature is used
<oneiric_> afaiui EdDSA-Blake2b-Ed25519 can also do blinding needed for encrypted lease sets
<oneiric_> 5. Confirm next meeting time
<oneiric_> same time two weeks?
<kinghat> yup
<oneiric_> right on, meeting over. thanks to all for attending

6.6 KiB Raw Blame History

Logs

6.6 KiB

Raw Blame History