+1 LGTM, thanks.
On Wed, May 8, 2024 at 9:56 PM Qinkun Bao wrote:
> +1
>
> Thanks!
>
> On Wed, May 8, 2024 at 9:50 PM Mingshen Sun wrote:
>
> > +1 approve
> >
> > Thanks!
> >
> > On Wed, May 8, 2024 at 8:51 PM Yuan Zhuang wrote:
> >
> > > Hi community,
> > >
> > > I'm initiating a vote thread
+1, thanks.
On Mon, Jun 12, 2023 at 8:11 AM Mingshen Sun wrote:
> +1 approve.
>
> I have tested the building.
>
> Mingshen
>
> On Mon, Jun 12, 2023 at 5:26 AM He Sun wrote:
>
> > Hi all,
> >
> > I am pleased to be calling this vote for the release of
> > Apache Teaclave (incubating) 0.6.0 (rel
+1, thanks.
On Tue, May 23, 2023 at 7:53 PM Yuan Zhuang wrote:
> +1
>
> On 2023/05/22 02:49:45 He Sun wrote:
> > [VOTE] Release Apache Teaclave (incubating) v0.5.1-rc.2
> > Hi all,
> >
> > I am pleased to be calling this vote for the release of
> > Apache Teaclave (incubating) 0.5.1 (release can
LGTM +1, thanks.
On Mon, Mar 27, 2023 at 8:02 PM gaoyingchun wrote:
> +1, vote up, thanks.
>
>
> -邮件原件-
> 发件人: He Sun
> 发送时间: 2023年3月27日 10:34
> 收件人: dev@teaclave.apache.org
> 主题: Re: [VOTE] Release Apache Teaclave (incubating) v0.5.0-rc.1
>
> Hi all,
>
> I am pleased to be calling this
appear in dev@list]
+ Gordon King
* No +/-0 votes
* No -1 votes
We will now proceed to prepare a new vote in gene...@incubator.apache.org.
Thank you to all who participated in the vote!
[1] https://lists.apache.org/thread/77zn0gd8kylxk2vl7o93s9hdoznc7dbh
https://lists.apache.org/thread
+1, vote up, thanks.
On 2023/02/06 01:29:54 Ran Duan wrote:
> +1 I support the Teaclave project to graduate from the Apache Incubator.( +1
> vote from private@teaclave.)
>
> > 2023年1月29日 下午12:19，Gordon 写道：
> >
> > Dear all in Teaclave community,
> >
>
cess.
> - Need more activities (features, roadmap, bug fixes) from the community.
Yes, we may bring more topics for community to discuss and participate, thanks.
>
Best Regards
Gordon
On 2023/02/01 17:05:39 Mingshen Sun wrote:
> Hi Gordon,
>
> I'm glad to hear that Teaclave
Dear all in Teaclave community,
We are starting a vote to graduate Apache Teaclave (incubating) as a Top
Level Project.
Apache Teaclave has incubated with the Apache Incubator since August 19th,
2019. During this period, the project has worked towards incubation with
the following milestones:
* T
## Description
There are several unclosed files in 2 python script files.
## Type of change (select or add applied and delete the others)
- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or featur
> The format pipeline seems failed:
> https://github.com/apache/incubator-teaclave/runs/5526163805?check_suite_focus=true
>
> Please use `make format` to format the code. Thanks!
Sure, let me check it out. thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/
## Description
Fix a message typo of TeaclaveException in teaclave.py
## Type of change (select or add applied and delete the others)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature th
There is a minor bug that appears on the `community` webpage. The following
`Archive` linked to `commit mail-list` not the `dev`
dev@teaclave.apache.org: A list for discussion on Teaclave
development including design proposal, release
announcements, meetup schedules, and commnity voting, etc.
[
### Motivation & problem statement
This feature is associated with #525, it should be booted at the LibOS side
before the workload get started. this feature is required to handle the
lifecycle of agent, the remote streams access and remote attestation.
### Proposed solution
this feature needs to
To my understand, the current local executors load their workload in the form
of in-memory byte stream. should LibOS based remote executor load its workload
in the similar way and the workload byte stream is transmitted through trusted
RPC ? Thanks.
--
You are receiving this because you are su
### Motivation & problem stat
This feature is related to #525 , There is mechanism to protect the runtime
binary of SGX enclave through CPL, so It might be reasonable to support the
encrypted payload, particularly used in remote LibOS executing scenarios. the
secrets should be able to get provi
The [crate cmake](https://crates.io/crates/cmake) is capable to manage the
build of native code well. it looks possible to address the problem of
separated rust codes in LSP.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I have fixed in PR #561. Please help to review and approve this PR (we won't
> merge any PR without review). Thanks.
Will review and verify it, thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ap
I found there seems no straightforward way to prepare a development environment
for containerized Teaclave services. I think it could improve the collaboration
efficiency and dev. productivity if we can streamline it using standard
approaches with comprehensive documentation.
Firstly, I often us
The CI identified the following issue.
Is it related to this PR? anything I should fix in this PR? thanks.
--
You are receiving this because you are subscribed to this thread.
Reply to
> I see several docs also contain instructions to use `docker-compose` to start
> services. Can you also change these? Thanks.
>
> * `docs/my-first-function.md`
> * `docs/azure-confidential-computing.md`
sure, will do. thanks.
--
You are receiving this because you are subscribed to this thread
My colleague helped me to identified an issue on his icelake server, I will add
a fixup on top of this PR, thanks.
--
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/pull/559#issueco
## Description
Added a bash script to detect sgx device and aesm service
heuristically, and start teaclave services without needing to specify
corresponding docker compose file manually. this script can detect and
handle containerized aesm service as well.
Fixes #553
## Type of change (select or
## Description
This patch simply adds the missing container name of teaclave-file-service in
DCAP docker compose file.
Fixes #557
## Type of change (select or add applied and delete the others)
- [X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change whic
The container name of `teaclave-file-service` has been specified in legacy SGX
docker compose file but not in DCAP one. it should be assigned a explicit name
as legacy one does to a make it consistent and reusable.
--
You are receiving this because you are subscribed to this thread.
Reply to th
Under the `docker` folder, it contains 2 identical files as follows. Is it
necessary to keep both of them ? thanks.
--
You are receiving this because you are subscribed to this thread
@mssun Sounds good to me +1, thanks.
--
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/issues/553#issuecomment-920550194
@mssun As we discussed, It is quite challenging to maintain the security model
for this integration because the GSGX is not designed to be integrated in API
level, it has to be running in external processes, the secrets and encrypted
workload/inputs/arguments are required to be exchanged with a
@mssun Alternatively, we can ask user to create a bind volume using the
following command if they don't use containerized aesmd service.
```
docker volume create --driver local \
--opt type=none \
--opt device= /var/run/aesmd\
--opt o=bind aesmd-socket
```
In addition, It is already provided as c
### Motivation & problem statement
As recommended in [Intel Linux SGX repo.](https://github.com/intel/linux-sgx),
the aesmd service is to be built and run as a [containerized
service](https://github.com/intel/linux-sgx/blob/master/docker/build/build_and_run_aesm_docker.sh#L41).
it created a [nam
Hi Folks,
FYI
Summary
The in-tree Intel® SGX DCAP driver is in Ubuntu kernels 5.11 & newer. There is
a known bug that affects kernels newer than 5.11.16. The bug has been
experienced when setting up a SGX based LibOS on an ICX SGX-enabled server with
kernel 5.11.17 as well as stable kernels 5.
Closed #546.
--
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/issues/546#event-5177519238
The problem solved, thanks.
--
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/issues/546#issuecomment-901482402
@ya0guang @mssun Thank you for the clarification. However, I still see some
workspaces, e.g. `executor` which didn't get indexed either way because they
seems not be included in both Cargo.toml files as workspace members.
--
You are receiving this because you are subscribed to this thread.
Re
### Motivation & problem statement
The code analyzer cannot correctly identify this rust project and its
workspaces corresponding to each subdirectories.
### Proposed solution
Adding a top-level Cargo.toml, this configures a virtual workspace – a
workspace that is only a container for member pa
## Description
The cmake `pkg_check_modules` relies on `PkgConfig` to check the version of
`libsgx_urts`.
It just reported that the `Intel SGX SDK (version 2.12.100.3) is not found or
version not matched.` if `PkgConfig` not been correctly installed. so it is
necessary to check and prompt user
Yes, I checked but it doesn't work.
--
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/issues/544#issuecomment-899986133
Switched to a new ICX server (Ubuntu 20.04.2 LTS), Identified the following
issue.
```
-- Found Git: /usr/bin/git (found version "2.25.1")
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Loo
@hanboa Thank you for this question, Yes, you are right, the attestation flow
is not explicitly shown here, In this design draft, we consider to retrieve the
`quote` from the component `Teaclave premain`, honestly, it is not a graceful
way to fetch it through this customized component, I propose
We drafted the design of GSGX enabling on Teaclave, Please review. thanks.
https://user-images.githubusercontent.com/10856796/128062600-88418e3a-dcec-4107-bc2a-8a390958dcf5.png";>
[teaclave_libos_gsgx.pdf](https://github.com/apache/incubator-teaclave/files/6926126/teaclave_libos_gsgx.pdf)
--
Yo
@mssun, thank you for the suggestion. regarding `Provide interfaces for any
libOS executors`, the 3rd-party libOS would be running in a separate
process/enclave space, should we keep it running or once per each request ?
thanks.
--
You are receiving this because you are subscribed to this thre
Hi @ya0guang I'm studying the PR #504 as a guide to adding Graphene as an
executor. In the example script
[wasm_simple_add.py](https://github.com/apache/incubator-teaclave/pull/504/files#diff-386761b79979c0852f0de51f53304f32ff8880ffb5733cc5e059899a6b3b4e2d),
the [payload_file:
wasm_simple_add_p
In addition, `Graphene project` licensed as [GPL
v3.0](https://github.com/oscarlab/graphene/blob/master/LICENSE.txt) along with
an
[addendum](https://github.com/oscarlab/graphene/blob/master/LICENSE.addendum.txt),
but it is not permissive compatible with `Apache 2`, the page
[GPL-compatibility
Thank you all for adding me as a mentor to Teaclave community !
Gordon.
On 2021/07/26 05:46:51, Mingshen Sun wrote:
> Dear Teaclave community,
>
> Let's welcome our new mentor - Gordon [1]. Gordon is from Apache
> Mnemonic PMC and Intel.
>
> Gordon is working closel
Hi @mssun, as we talked, the `Graphene` will download several dependent 3rd
party's codebases during building time. e.g.
[glibc](https://github.com/oscarlab/graphene/blob/9f0943e39432e5440066c8448780a08eb4254c77/LibOS/Makefile#L117),
[mbedtls](https://github.com/oscarlab/graphene/blob/30013c67
Hi Mingshen,
May I have the Zoom link to participate the monthly meeing ? thanks.
Gordon.
On 2021/07/21 21:08:25, Mingshen Sun wrote:
> Dear Teaclave community,
>
> We are going to have the monthly Teaclave (virtual) meetup. The
> meetup in this month is scheduled on July
## Description
Fix a minor typo issue in `development-tips.md`
`parth::to::module=level => path::to::module=level`
Fixes # (528)
You can view, comment on, or merge this pull request online at:
https://github.com/apache/incubator-teaclave/pull/529
-- Commit Summary --
* A minor typo fixes in
Thank you for the hint.
--
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/issues/528#issuecomment-885335414
Hi @ya0guang, Glad to know you also got interested in this. Yes. as you
mentioned, the Graphene forwards many `syscalls` to untrusted host, more
specifically, `41 SGX OCALLs` to untrusted PAL layer of Graphene and do some
kinds of security check. it is similar to have some `unsafe calls` to exte
In the [attestation](https://teaclave.apache.org/docs/codebase/attestation/)
page, the way to binding is `We make the certificate cryptographically bound
to a specific enclave instance by adding the public key of the certificate in
the attestation report.`, how the service certification can get
There is a minor type issue in a webpage linked by
https://teaclave.apache.org/docs/development-tips/
`parth::to::module=level` => `path::to::module=level`
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/
## Description
Fix an issue about `Python.h not found` when compiling `acs_py_enclave.c`
Fixes # (526)
## Type of change (select or add applied and delete the others)
- [ X] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ]
On my system, the following error message shown up when compiling
acs_py_enclave.c
`
Scanning dependencies of target pycomponent
[ 34%] Building C object
CMakeFiles/pycomponent.dir/intermediate/acs_py_enclave.c.o
/home/gordon/incubator-teaclave/build/intermediate/acs_py_enclave.c:29:10:
fatal
Hi @mssun, Thanks you very much for the detailed explanation on leveraging
LibOS kind system in Teaclave.
It is very helpful for us to work on this effectively. the GSGX so far only has
relative stable CLI interface and its internal APIs are not designed for 3rd
party integration since it's AP
[Graphene](https://grapheneproject.io/)
--
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/issues/525#issuecomment-881623673
### Motivation & problem statement
As #502 questioned that the integration with a LibOS would be interesting
feature for a FaaS platform because allowing to run regular app. directly in
enclave along with LibOS handling most syscalls may further improve the
usability and simplify the usage model
We may try to integrate with Graphene LibOS, Let me create a new feature
request ticket to handle this, thanks.
--
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/issues/502#issuecom
## Description
Just a typo fix
## Type of change (select or add applied and delete the others)
- Document typo fix
You can view, comment on, or merge this pull request online at:
https://github.com/apache/incubator-teaclave/pull/524
-- Commit Summary --
* Fix a typo of data_owner
-- File
Dear Teaclave community,
I'm an Apache IPMC, this project looks very promising to me, I'd like to
become a mentor for this and make contributions as needed, Thanks.
Best regards
Gordon.
58 matches
Mail list logo
