Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove some modules from Mbed TLS 3.0 #4030

Closed
daverodgman opened this issue Jan 14, 2021 · 4 comments
Closed

Remove some modules from Mbed TLS 3.0 #4030

daverodgman opened this issue Jan 14, 2021 · 4 comments

Comments

@daverodgman
Copy link
Contributor

daverodgman commented Jan 14, 2021

Remove these modules and associated includes, etc:

Wrapper for PKCS#11 library libpkcs11-helper (library/pkcs11.c)
HAVEGE (library/havege.c)
X.509 test certificates (library/certs.c) (this should remain under tests, but not in the core library)
RC4 cipher
Net socket
Memory allocator

This task needs review to verify the list of modules

@yanesca
Copy link
Contributor

yanesca commented Jan 25, 2021

  • Wrapper for PKCS#11 library libpkcs11-helper (library/pkcs11.c) has been discussed on the mailing list and confirmed for removal
  • HAVEGE (library/havege.c) has been discussed on the mailing list and confirmed for removal
  • X.509 test certificates (library/certs.c) has been discussed, there were no objections, technical details might need design review.
  • I don't think we want to remove RC4 from the library just for the default configuration and is part of Remove unnecessary compile-time options from config.h #4035 and Change config.h defaults #4036.
  • memory_buffer_alloc.c we still want to remove it, but there were objections, several users are relying on it, we shouldn't be removing it in a rush
  • net_socket.c and timing.c, there is no decision so far, @mpg proposes to move them into programs/, @gilles-peskine-arm is on the opinion that we should move them into a platform_posix.c and a platform_windows.c modules within the library. I suggest we move these two to a separate issue and don't block the rest while we are coming up with an approach

@gilles-peskine-arm
Copy link
Contributor

I think that for task management, each module should have its own task. Removing modules is not a generic endeavor.

@daverodgman
Copy link
Contributor Author

I think breaking these into separate tasks is much better than tracking them all together here. I'll add individual tasks and close this one when done.

@daverodgman
Copy link
Contributor Author

Closing as this has been captured in individual issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants