Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Moritz Eckert
    @m1ghtym0
    :wave: Hi everyone!
    Felix Schuster
    @flxflx
    Hi Moritz!
    johnnyreim
    @johnnyreim
    Hi everyone :) I just followed the getting started guide for marblerun and set up a small toy service on AKS. how can I add more pods?
    Moritz Eckert
    @m1ghtym0
    :wave: Hi @johnnyreim! Cool stuff! Depends if you want to add a new type of service or you just want to scale up an existing service. For the former, you'll need to add a new entry to the manifest (see https://marblerun.sh/docs/tasks/add-service/) and redeploy your application (see https://marblerun.sh/docs/tasks/set-manifest/). The latter is simple:-) Just follow the default approach for scaling an application with kubernetes. For example run kubectl scale deployment <your deployment> --replicas <#replicas>
    Felix Schuster
    @flxflx
    Should we rename the secrets type "raw" to "random-bytes"?
    Felix Schuster
    @flxflx
    I believe we should enforce the following wrt. the Packages section: either UniqueID or SignerID,ProductID, SecurityVersion should work. UniqueID+SecurityVersion doesn't make much sense etc.
    Moritz Eckert
    @m1ghtym0

    Should we rename the secrets type "raw" to "random-bytes"?

    I like that idea, "raw" could be a bit ambiguous here. It also overlaps with the encoding type "raw".

    I believe we should enforce the following wrt. the Packages section: either UniqueID or SignerID,ProductID, SecurityVersion should work. UniqueID+SecurityVersion doesn't make much sense etc.

    With the goal in mind of giving people guidance and the aspect that those are the only two combinations of values that make sense in practice the restriction could actually be beneficial. In case someone comes up with another combination in an obscure use-case we can easily add that later on.

    Nils Hanke
    @Nirusu
    I'm also in for renaming "raw", but should we go for "random-bytes", or maybe even something more suggestive like "symmetric-key"?
    Felix Schuster
    @flxflx
    we derive it with a KDF right? Let's go with symmetric-key then
    Nils Hanke
    @Nirusu
    Yup, we do. Alright, we'll go with it!
    Thomas Tendyck
    @thomasten
    KDF only for unique secrets. Couldn't "raw" secrets be used for other things than symmetric keys?
    Nils Hanke
    @Nirusu
    After a discussion, we'll switch to symmetric-key. Also, I'll keep track of documentation changes for "unreleased" Marblerun versions in the marblerun.sh repo in the dev branch, guess that's better than constantly creating new branches for every single change ;)
    Felix Schuster
    @flxflx
    Sounds good!
    piotr-roslaniec
    @piotr-roslaniec
    Hello. Is there any date for general availability of the Edgeless DB?
    Moritz Eckert
    @m1ghtym0
    Hi @piotr-roslaniec ! We plan to release it in Q2 this year.
    piotr-roslaniec
    @piotr-roslaniec
    Thanks, @m1ghtym0!
    Marcus Brandenburger
    @mbrandenburger
    Hi, just playing with ego. Trying to run some sample go code. It seems os.Argsare correctly forwarded to my app inside the enclave, however, using os.Getenv does not work. Is this an expected behavior /limitation? Thanks
    Thomas Tendyck
    @thomasten
    Hi @mbrandenburger ! Yes, it is. Currently, environment variables are only readable from within the enclave if they start with "EDG_". But we are working on making this flexible via a whitelist within enclave.json.
    Marcus Brandenburger
    @mbrandenburger
    ah cool; indeed this works!
    Marcus Brandenburger
    @mbrandenburger
    another question. I extended my sample app with some cgo calls. Building seems to work without and error but ego sign helloworld returns double free or corruption (!prev). Is there a way to enable more verbose output to see what is going wrong here?
    Thomas Tendyck
    @thomasten
    try setting env var OE_LOG_LEVEL=INFO
    Marcus Brandenburger
    @mbrandenburger
    this does not affect ego sign:
    OE_LOG_LEVEL=INFO ego sign helloworld
double free or corruption (!prev)
    although OE_LOG_LEVEL=INFO ego run ... shows some more debugging output, at least for my sample app without cgo
    Thomas Tendyck
    @thomasten
    try stdbuf -o0 ego sign helloworld
    Marcus Brandenburger
    @mbrandenburger

    that looks much better.

    stdbuf -o0 ego sign helloworld
2021-02-25T14:27:12+0000.659841Z [(H)ERROR] tid(0x7f323f586d40) | Unsupported elf relocation type 1
 (oe_result_t=OE_UNSUPPORTED_ENCLAVE_IMAGE) [/edgelessrt/build/3rdparty/openenclave/openenclave-src/host/sgx/elf.c:elf64_load_relocations:1923]
2021-02-25T14:27:12+0000.659914Z [(H)ERROR] tid(0x7f323f586d40) | :OE_INVALID_IMAGE [/edgelessrt/build/3rdparty/openenclave/openenclave-src/host/sgx/loadelf.c:_load_elf_image:434]
2021-02-25T14:27:12+0000.659932Z [(H)ERROR] tid(0x7f323f586d40) | :OE_INVALID_IMAGE [/edgelessrt/build/3rdparty/openenclave/openenclave-src/host/sgx/loadelf.c:oe_load_elf_enclave_image:877]
double free or corruption (!prev)

    It seems that OE complains when linking the lib that is used for the cgo call.