@volcano0dr any comment on this would be appreciated
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/409#issuecomment-1848440711
You are receiving this because you are subscribed to this thread.
Message ID:
@volcano0dr any news on the official release of 2.0.0? We'd be tempted to
switch to 2.0.0 but would prefer the release to be official
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/445#issuecomment-1838624586
You are receiving th
Pardon my impatience, @volcano0dr: we really need rustc 1.70.0 or newer and it
is getting urgent.
Could you give an updated ETA please?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/445#issuecomment-1823961719
You are receiving
any ETA here?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/445#issuecomment-1719290998
You are receiving this because you are subscribed to this thread.
Message ID:
when can we expect the release of 1.1.4?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/360#issuecomment-962151062
This SDK is behind Intel's SDK for quite a while already and the supported rust
compiler is very old.
We currently face a deadlock because
https://github.com/dtolnay/proc-macro2/pull/296 breaks our build. We can't
downgrade, because other dependencies request proc-macro2-1.0.29. But we can't
u
Our reference implementation is:
https://github.com/paritytech/substrate/tree/master/client/rpc-api
We don't necessarily need to support all transport protocols. `wss://` is
enough.
```
jsonrpc-core
jsonrpc-core-client
jsonrpc-pubsub (?)
jsonrpc-client-transports
jsonrpc-derive
jsonrpc-ws-server
I fear we will need more to get wss:// into the enclave working. at least
jsonrpc-ws-server and its dependencies
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/304
We're currently forking jsonrpc for use in our enclave. Thanks @dingelish for
your previous upgrades on `serde`.
We're now stuck. If you build
https://github.com/scs/substraTEE-worker/tree/upgrade-deps/enclave
(build it easily in our docker:
https://www.substratee.com/howto_worker.html#using-doc
@dingelish Sorry for my delay. I can confirm that `export
SGX_SDK=/opt/intel/sgxsdk` makes my build work after a `cargo update`. Without
it, it fails with the above mentioned error
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on G
and we always use `/opt/intel/sgxsdk` as a symlink to the desired release
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#issuecomment-73749
thanks a lot for reproducing. I will try again with cargo update
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#issuecomment-737466082
anyway, I have a temporary fix by just updating log-sgx with `cargo update -p
log`. Still, this is a brittle situation because the build won't work anymore
after a `cargo update`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on Git
@dingelish it seems that `make clean` doesn't help neither.
I see that you have retagged 1.1.3 to include support for newer compiler (the
old tag pointed to 254368badb9eb2d4cdab631a34e234bf6e54e585). I think
re-tagging is a dangerous practise if you have other repos depending on yours.
Why not j
sorry, I forgot this:
https://github.com/encointer/encointer-node/tree/sgx-master#building
you need LLVM >9
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#issu
exactly. that will reproduce the missing commit in log-sgx.
Then you can do cargo update in root and ./enclave dirs to reproduce the error
above
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incu
sure. I'm trying to build this:
https://github.com/encointer/encointer-worker/commits/v0.6.15
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#issuecomment-73609
It seems you have rebased because with our current Cargo.lock it won't build
anymore on a new clone because the commit can't be found. After doing `cargo
update` (observing that you have re-tagged sgx_1.1.3) I now get: the following
error:
```
Compiling sgx_trts v1.1.3
(https://github.com/ap
Closed #294.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#event-4050983759
awesome, thank you!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/294#issuecomment-735672410
Don't know where to put this request because mesalock-linux repos have no
issues.
We need to patch crate-io `log crate with the mesalock one, but because our
dependency `sp-core` requires 0.4.11, cargo won't apply the patch as mesalock
is at 0.4.8
Would be great to see an upgrade to >= 0.4.11.
this approach is acceptable. important for us is that tests are collected
automatically and results are summarized clearly
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/
Is there any chance we can make `cargo test` work with [our enclave
code](https://github.com/scs/substraTEE-worker/tree/master/enclave)?
it would be great if we could use standard `cargo test`. Right now we can only
do [handmade
testing](https://github.com/scs/substraTEE-worker/blob/master/work
tricky one. Basically I think it is good practise to have one repo per version
number and vice versa. This way this issue couldn't happen. But as you're not
in charge of the upstream repo we're out of luck. You could of course split the
fork into single repos, but that makes rebasing a pain.
Ma
The `+` makes sense IMO
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/206#issuecomment-604892379
as this is probably not a bug of this sdk, I've filed an issue with cargo:
https://github.com/rust-lang/cargo/issues/7951
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/is
`cargo nono check` warns about exactly the same crates in both commits
```
webpki: FAILURE
log: FAILURE
serde_json: FAILURE
sgx-externalities: FAILURE
env_logger: FAILURE
rustls: FAILURE
num-bigint: FAILURE
webpki-roots: FAILURE
substratee-stf: FAILURE
chrono: FAILURE
base64: FAILURE
yasna: FAILUR
When building
https://github.com/encointer/encointer-worker/commit/7252e20264e63c7dce11470922d7c2965378842e
with
```
cd enclave
make
```
I get an error:
```
error: duplicate lang item in crate `sgx_tstd` (which `palette_support` depends
on): `f32_runtime`.
|
= note: first defined in crate `s
I endorse your suggestion @dingelish. tag everywhere.
It's not perfect because you still don't know the upstream version. The
question is if you want to include that version in the tag too (We might have
discussed this before): `v1.2.3_sgx1.1.0`
--
You are receiving this because you are subsc
There are inconsistencies between referencing crates with `branch=mesalock_sgx`
and tag=`sgx_v1.1.0`
i.e. this here causes trouble:
https://github.com/mesalock-linux/rustls/blob/d9a91f5037f5c85f761279d97b838256285a1314/Cargo.toml#L19
rustls `tag sgx_v1.1.0` depends on webpki `branch=mesaloch_sgx
@dingelish: It seems that logging somehow got broken in v1.1.0
If I apply the following patch to teaclave-sgx-sdk tag=v1.1.0
```
diff --git a/samplecode/logger/enclave/Cargo.toml
b/samplecode/logger/enclave/Cargo.toml
index 95e2550d..120a5e52 100644
--- a/samplecode/logger/enclave/Cargo.toml
+++
Closed #203.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave-sgx-sdk/issues/203#event-2999230492
the problem occurred because I was accidentalley building sgx_ucrypto for the
target wasm32-unknown-unkown too. Had to fix the toml to make this dependency
optional for `std` use case
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
I'm trying to use `sgx_ucrypto::SgxEccHandle` to verify a signature
[reproduce with this
code](https://github.com/scs/substraTEE-node/tree/ra_improvements)
When I do
```
cargo +nightly-2019-11-25 build
```
I get the following errors:
```
error[E0432]: unresolved imports `libc::size_t`, `libc::c
34 matches
Mail list logo
