Bug#983501: ITP: python-asyncache -- Helpers to use cachetools with asyncio
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: python-asyncache Version : 0.1.1 Upstream Author : Hepehx * URL : https://github.com/hephex/asyncache * License : Expat Programming Lang: Python Description : Helpers to use cachetools with asyncio This package contains async wrapper to use Python cachetools module in asynchronous code. This package will be maintained within the Debian Python Module Team (DPMT).
Bug#983482: ITP: bcnc -- GRBL CNC command sender, autoleveler and g-code editor
Package: wnpp Severity: wishlist Owner: Romain Porte X-Debbugs-Cc: debian-devel@lists.debian.org, deb...@microjoe.org * Package name: bcnc Version : 0.9.14.316 Upstream Author : Tomas Mudrunka * URL : https://github.com/vlachoudis/bCNC * License : GPL Programming Lang: Python Description : GRBL CNC command sender, autoleveler and g-code editor GrblHAL (formerly GRBL) CNC command sender, autoleveler, g-code editor, digitizer, CAM and swiss army knife for all your CNC needs I intent to maintain this package under the umbrella of the Debian Python Team.
Re: New service: https://debuginfod.debian.net
On Wednesday, February 24 2021, Steinar H. Gunderson wrote: > On Wed, Feb 24, 2021 at 10:25:02AM -0500, Sergio Durigan Junior wrote: >> Hm, that's a bummer. I mean, you can certainly set up an instance for >> you, but it takes a lot of time to mirror debian-debug (some days, >> depending on your network connection). I don't know if that would be >> interesting to you, because then you will have to maintain the mirror >> up-to-date and all. > > I assume there's rsync somehow. There is not. At least, I could not figure out how to use rsync with the debian-debug. After many failed attempts (which included trying archsync, ftpsync, etc.), I just went with aptly. > Out of curiosity, how large is the debug repository? IIRC almost 2.5TB. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: New service: https://debuginfod.debian.net
On Wed, Feb 24, 2021 at 10:25:02AM -0500, Sergio Durigan Junior wrote: > Hm, that's a bummer. I mean, you can certainly set up an instance for > you, but it takes a lot of time to mirror debian-debug (some days, > depending on your network connection). I don't know if that would be > interesting to you, because then you will have to maintain the mirror > up-to-date and all. I assume there's rsync somehow. Out of curiosity, how large is the debug repository? /* Steinar */ -- Homepage: https://www.sesse.net/
Re: New service: https://debuginfod.debian.net
On Wed, 2021-02-24 at 16:58 +, Ian Campbell wrote:
Ugh, sorry, the quoting seems to have gone quite wrong there, let me
try again...
> On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
> Hello there,
>
> I would like to announce a new service that I have just configured
> for
> Debian: https://debuginfod.debian.net.
>
> debuginfod is a new-ish project whose purpose is to serve
> ELF/DWARF/source-code information over HTTP. It is developed under
> the
> elfutils umbrella. You can find more information about it here:
>
> https://sourceware.org/elfutils/Debuginfod.html
Sounds interesting, thanks!
If you would like to use the service, and if the service supports the
Debian distribution you are using (see below), all you have to do is
make sure that the following environment variable is set in your shell:
DEBUGINFOD_URLS="https://debuginfod.debian.net";
Currently, the elfutils and GDB packages in unstable and testing have
native support for using debuginfod. I will soon propose a change to
the elfutils package in order to make it be configured with our
debuginfod instance by default, so that users will be able to use the
service transparently.
What are the security implications for users/clients of using this or
more importantly enabling it by default?
Presumably clients have to trust that the server is not going to feed
them malicious debug info. Are the tools which consume this information
written to operate on completely untrusted inputs? It seems like many
of them could have been written historically with the assumption that
their inputs are mostly to be trusted. I suppose the use https helps
mitigate this at least a bit when it comes to a debian.{org,net}
service.
What about information leakage? apart from debugids does this leak
anything else to the server? On a quick look it seems like it might
potentially leak source code paths (at least the leaf bits) to things
being debugged -- does this mean that if a user is debugging private
software (perhaps unpublished or perhaps proprietary software for
$work) on a Debian system they are at risk of leaking the source
filenames if they run gdb on one of their binaries while debugging?
This might be a problem if it comes to enabling this transparently.
Thanks,
Ian.
Bug#983467: ITP: wolftpm -- Portable TPM 2.0 Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolftpm Version : 2.0.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolftpm/ * License : GPL-2+ Programming Lang: C Description : Portable TPM 2.0 Library wolfTPM is a portable, open-source TPM 2.0 stack with backward API compatibility, designed for embedded use. It is highly portable, and has native support for Linux. RTOS and bare metal environments can take advantage of a single IO callback for SPI hardware interface, no external dependencies, and compact code size with low resource usage. wolfTPM offers API wrappers to help with complex TPM operations like attestation and examples to help with complex cryptographic processes like the generation of Certificate Signing Request (CSR) using a TPM. - Provides all TPM 2.0 API’s in compliance with the specification. - Backward API compatibility. - Includes wrappers for the most common use cases, like Key Generation, NV memory, RSA encrypt/decrypt, ECC sign/verify, ECDH, and others. - Provides examples for the advanced use cases, like Attestation (TPM 2.0 Quote), Certificate Signing Request (CSR), generation of signed timestamp (TPM 2.0 GetTime), and others. wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983454: ITP: image-analyzer -- GTK3-based utility for CD/DVD image analysis
Package: wnpp Severity: wishlist Owner: Matteo Bini * Package name: image-analyzer Version : 3.2.4 Upstream Author : Rok Mandeljc * URL : https://cdemu.sourceforge.io/about/analyzer/ * License : GPLv2 Programming Lang: C Description : GTK3-based utility for CD/DVD image analysis Image Analyzer is a GTK3-based utility for CD/DVD image analysis and manipulation, with following functionality: - disc image layout visualization - reading of sector data from image - analysis of error correction and detection codes in sector main and subchannel data - retrieval of disc (DVD) structures, if available - visualization of disc topology (DPM) data, if available - image format conversion - logging facilities for debugging image-analyzer_3.2.4.orig.tar.bz2 Description: BZip2 compressed data
Re: New service: https://debuginfod.debian.net
On Tue, 2021-02-23 at 22:53 -0500, Sergio Durigan Junior wrote:
Hello there,
I would like to announce a new service that I have just configured for
Debian: https://debuginfod.debian.net.
debuginfod is a new-ish project whose purpose is to serve
ELF/DWARF/source-code information over HTTP. It is developed under the
elfutils umbrella. You can find more information about it here:
https://sourceware.org/elfutils/Debuginfod.html
Sounds interesting, thanks!
If you would like to use the service, and if the service supports the
Debian distribution you are using (see below), all you have to do is
make sure that the following environment variable is set in your shell:
DEBUGINFOD_URLS="https://debuginfod.debian.net";
Currently, the elfutils and GDB packages in unstable and testing have
native support for using debuginfod. I will soon propose a change to
the elfutils package in order to make it be configured with our
debuginfod instance by default, so that users will be able to use the
service transparently.
What are the security implications for users/clients of using this or
more importantly enabling it by default?
Presumably clients have to trust that the server is not going to feed
them malicious debug info. Are the tools which consume this information
written to operate on completely untrusted inputs? It seems like many
of them could have been written historically with the assumption that
their inputs are mostly to be trusted. I suppose the use https helps
mitigate this at least a bit when it comes to a debian.{org,net}
service.
What about information leakage? apart from debugids does this leak
anything else to the server? On a quick look it seems like it might
potentially leak source code paths (at least the leaf bits) to things
being debugged -- does this mean that if a user is debugging private
software (perhaps unpublished or perhaps proprietary software for
$work) on a Debian system they are at risk of leaking the source
filenames if they run gdb on one of their binaries while debugging?
This might be a problem if it comes to enabling this transparently.
Thanks,
Ian.
Bug#983453: ITP: gcdemu -- GTK3-based GUI for controlling CDEmu daemon
Package: wnpp Severity: wishlist Owner: Matteo Bini * Package name: gcdemu Version : 3.2.4 Upstream Author : Rok Mandeljc * URL : https://cdemu.sourceforge.io/about/gcdemu/ * License : GPLv2 Programming Lang: C Description : GTK3-based GUI for controlling CDEmu daemon GTK3-based GUI for controlling CDEmu daemon. It is part of the CDEmu software suite, a free, GPL CD/DVD-ROM device emulator for Linux. It provides a graphic interface that allows performing the key tasks related to controlling the CDEmu daemon, such as loading and unloading devices, displaying devices' status and retrieving/setting devices' debug masks. In addition, it listens to signals emitted by CDEmu daemon and provides notifications via libnotify (provided that python bindings are installed). gcdemu_3.2.4.orig.tar.bz2 Description: BZip2 compressed data
Re: First virtual Bug Squashing Party in Salzburg/Austria April 24-25 2021
On Sun, Feb 7, 2021 at 7:13 PM Bernd Zeimetz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > First virtual Bug Squashing Party in Salzburg/Austria April 24-25 2021 > === > > Let's release bullseye! (.. or make the time to the release shorter ..) > > As the pandemic situation does not allow us to have the usual BSP > happen at our office [CONOVA] in Salzburg, we would like to organize a > virtual Bug Squashing Party instead [BSPSBG]! > > [CONOVA] https://www.conova.com/ > [BSPSBG] https://wiki.debian.org/BSP/2021/04/virtual-Salzburg hey, how to add my name to attendee list in above link? > > > The exact details are TBA, but most likely we'll have a matrix bridge > to IRC and jitsi, so people can join with audio/video/text only. > > Our plan... > > * is to ship goodie bags to all active participiants within > Europe. For those outside of the european tax area we'll try to find > a solution together with you, but can't make any promises. > As this requires lots of organization, please register as soon as you > know that you'll participate. We'll ask you for shipment details > then. > > * Yoga (with the office chair) and/or sports intermissions. Our > trainers will find suitable exercises for everybody. Please note that > joning with video and audio is required. Let us know if you are > interested to make sure we can plan ahead. > > * having virtual Datacenter Tours trough our brand new datacenter. > instead of having the usual hike trough our office/DC building, we'll > take you on a virtual tour trough our new DC building in the south of > Salzburg. > > * gaming intermissions. Maybe pioneers or other group games from the > Debian games collection. > > > The "official" parts will happen between 12pm and 10pm on the 24/25th > of April, but of course you'll be able to squash bugs around the clock. > > > Even if you are not a Debian Developer or Contributor yet, but > interested in fixing bugs and helping Debian, don't hesitate to join! > There will be enough people around to sponsor your uploads. More > information about BSPs and RC-Bugsquashing can be found at [WIKBSP], > [PRIMER] and [BDOR-C]. > > [WIKBSP] http://wiki.debian.org/BSP > [PRIMER] http://people.debian.org/~vorlon/rc-bugsquashing.html > [BDOR-C] http://bugs.debian.org/release-critical/ > > > Hope to see you here! > > Bernd > > - -- > Bernd ZeimetzDebian GNU/Linux Developer > http://bzed.dehttp://www.debian.org > GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEE7KHj8o4RJDLUhd2V6zYXGm/5Q18FAmAf7RcACgkQ6zYXGm/5 > Q188Hg/8CkjzorowkF7iJ94j0XT7jWBE6NSW7PO2WvmraK30tCzGNwmbPKXT0hmT > mESvYbBdH24oZQNcXQL/KmSDniLJIszjBenrn9t/BIoVUhQL9U8s98AhwtEm0tnr > oKVn3VVjDwIsqwcWehe+FAmtKVGhGMzKGqdGbiYLnlPkIepAOefldPl/uPoUImuq > YPEfXDeiEEzyH83bzmfKjELj+cR0U32VumGWk5guzddAsLlGB2LXgcW4N9klctN6 > qpwA0hZ2V2c6KoBFv8S3TyjeScYMcu50kMGgj9cY8OV0TBgwe0vQsdPEBqrFifEW > MtFMVbO4xgAWblxqJ9vnlAa276OP4BLUkPlN+hYuw4UMEMPk9WyBGsa/lI3zDqq+ > IjyhyTBaWcrmkw9ahbP+yaudE/eXXbb/mHtGFaH/Ss56Z9dzZ8nb9xfuWkkMz75j > KvqWsNiaMGorDc38dzYpM2E2sloXBwR8KMlbD1MroBCqYS3dfBrfr3fSdk2DKxs8 > +gtUh4LMx3Xc/2wF/hY01VUUhdjVgj9VUvhE+RHQ4M4eWDH68GXgunFXDZf+YuVu > IyWa89uZl9M1WRlyQl3Wi3ZxWcHnAp0DjevwLHFRQH4qfYIHvQm0M/jigePNnG4S > 3K15VWAMmXRFxLHcmmMYdRj7yVUhhwyb87ZFif2W5ExzSRntkbc= > =CZsr > -END PGP SIGNATURE- >
Bug#983452: ITP: cdemu-client -- Command-line client for CDEmu daemon
Package: wnpp Severity: wishlist Owner: Matteo Bini * Package name: cdemu-client Version : 3.2.4-1 Upstream Author : Rok Mandeljc * URL : https://cdemu.sourceforge.io/about/client/ * License : GPLv2 Programming Lang: C Description : Command-line client for CDEmu daemon Simple command-line client for controlling CDEmu daemon. It is part of the CDEmu software suite, a free, GPL CD/DVD-ROM device emulator for Linux. It provides a way to perform the key tasks related to controlling the CDEmu daemon, such as loading and unloading devices, displaying devices' status and retrieving/setting devices' debug masks. cdemu-client_3.2.4.orig.tar.bz2 Description: BZip2 compressed data
Re: New service: https://debuginfod.debian.net
On Wednesday, February 24 2021, Christoph Berg wrote: > Re: Sergio Durigan Junior >> I would like to announce a new service that I have just configured for >> Debian: https://debuginfod.debian.net. > > Very cool! Thanks! >> Currently, the elfutils and GDB packages in unstable and testing have >> native support for using debuginfod. I will soon propose a change to >> the elfutils package in order to make it be configured with our >> debuginfod instance by default, so that users will be able to use the >> service transparently. > > Maybe the service should move to debuginfod.debian.*org* if it's going > to be a default. (Which I would like to see.) Yeah, I've been pestering Héctor on and off these past few weeks about it. My initial intention was to deploy this using a DSA sanctioned machine, but I understand that they are extremely busy right now (and I didn't want to wait), so I decided to go with a debian.net service. >> For now, debuginfod.debian.net is serving debug information symbols for >> the following Debian distributions: >> >> - unstable > > Can you add experimental? Yes! Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: New service: https://debuginfod.debian.net
On Wednesday, February 24 2021, Shengjing Zhu wrote: > On Tue, Feb 23, 2021 at 10:53:14PM -0500, Sergio Durigan Junior wrote: >> Hello there, >> >> I would like to announce a new service that I have just configured for >> Debian: https://debuginfod.debian.net. >> > > Thanks a lot for this great service. Thanks. > I have two questions. > > 1. Do you want to include contrib and nonfree as well? No, just main. > 2. Is this site mirror-able, or is the deploy scripts available somewhere? It is not mirror-able. Also, there are no deploy scripts: just some shell scripts that use aptly to mirror the debian-debug repository, and then a systemd service file for debuginfod. I intend to put these in a git repository soon-ish. >I tried this instance, but I got problems like: > >Download failed: Timer expired. Continuing without debug info for ... > >So I think it's benefit to setup an instance in my network area too. >For those like me, that don't have good quality network to European >datacenter. Hm, that's a bummer. I mean, you can certainly set up an instance for you, but it takes a lot of time to mirror debian-debug (some days, depending on your network connection). I don't know if that would be interesting to you, because then you will have to maintain the mirror up-to-date and all. Could you please send me more details (in private) about the failure you've seen? Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
Re: First virtual Bug Squashing Party in Salzburg/Austria April 24-25 2021
On Sun, Feb 7, 2021 at 7:13 PM Bernd Zeimetz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > First virtual Bug Squashing Party in Salzburg/Austria April 24-25 2021 > === > > Let's release bullseye! (.. or make the time to the release shorter ..) > > As the pandemic situation does not allow us to have the usual BSP > happen at our office [CONOVA] in Salzburg, we would like to organize a > virtual Bug Squashing Party instead [BSPSBG]! > > [CONOVA] https://www.conova.com/ > [BSPSBG] https://wiki.debian.org/BSP/2021/04/virtual-Salzburg hey how to add my name to attendee list in above link? > > > The exact details are TBA, but most likely we'll have a matrix bridge > to IRC and jitsi, so people can join with audio/video/text only. > > Our plan... > > * is to ship goodie bags to all active participiants within > Europe. For those outside of the european tax area we'll try to find > a solution together with you, but can't make any promises. > As this requires lots of organization, please register as soon as you > know that you'll participate. We'll ask you for shipment details > then. > > * Yoga (with the office chair) and/or sports intermissions. Our > trainers will find suitable exercises for everybody. Please note that > joning with video and audio is required. Let us know if you are > interested to make sure we can plan ahead. > > * having virtual Datacenter Tours trough our brand new datacenter. > instead of having the usual hike trough our office/DC building, we'll > take you on a virtual tour trough our new DC building in the south of > Salzburg. > > * gaming intermissions. Maybe pioneers or other group games from the > Debian games collection. > > > The "official" parts will happen between 12pm and 10pm on the 24/25th > of April, but of course you'll be able to squash bugs around the clock. > > > Even if you are not a Debian Developer or Contributor yet, but > interested in fixing bugs and helping Debian, don't hesitate to join! > There will be enough people around to sponsor your uploads. More > information about BSPs and RC-Bugsquashing can be found at [WIKBSP], > [PRIMER] and [BDOR-C]. > > [WIKBSP] http://wiki.debian.org/BSP > [PRIMER] http://people.debian.org/~vorlon/rc-bugsquashing.html > [BDOR-C] http://bugs.debian.org/release-critical/ > > > Hope to see you here! > > Bernd > > - -- > Bernd ZeimetzDebian GNU/Linux Developer > http://bzed.dehttp://www.debian.org > GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEE7KHj8o4RJDLUhd2V6zYXGm/5Q18FAmAf7RcACgkQ6zYXGm/5 > Q188Hg/8CkjzorowkF7iJ94j0XT7jWBE6NSW7PO2WvmraK30tCzGNwmbPKXT0hmT > mESvYbBdH24oZQNcXQL/KmSDniLJIszjBenrn9t/BIoVUhQL9U8s98AhwtEm0tnr > oKVn3VVjDwIsqwcWehe+FAmtKVGhGMzKGqdGbiYLnlPkIepAOefldPl/uPoUImuq > YPEfXDeiEEzyH83bzmfKjELj+cR0U32VumGWk5guzddAsLlGB2LXgcW4N9klctN6 > qpwA0hZ2V2c6KoBFv8S3TyjeScYMcu50kMGgj9cY8OV0TBgwe0vQsdPEBqrFifEW > MtFMVbO4xgAWblxqJ9vnlAa276OP4BLUkPlN+hYuw4UMEMPk9WyBGsa/lI3zDqq+ > IjyhyTBaWcrmkw9ahbP+yaudE/eXXbb/mHtGFaH/Ss56Z9dzZ8nb9xfuWkkMz75j > KvqWsNiaMGorDc38dzYpM2E2sloXBwR8KMlbD1MroBCqYS3dfBrfr3fSdk2DKxs8 > +gtUh4LMx3Xc/2wF/hY01VUUhdjVgj9VUvhE+RHQ4M4eWDH68GXgunFXDZf+YuVu > IyWa89uZl9M1WRlyQl3Wi3ZxWcHnAp0DjevwLHFRQH4qfYIHvQm0M/jigePNnG4S > 3K15VWAMmXRFxLHcmmMYdRj7yVUhhwyb87ZFif2W5ExzSRntkbc= > =CZsr > -END PGP SIGNATURE- >
Bug#983450: ITP: wolfmqtt -- Lightweight client library for the MQTT protocol
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolfmqtt Version : 1.8.0 Upstream Author : David Garske * URL : https://www.wolfssl.com/products/wolfmqtt/ * License : GPL-2+ Programming Lang: C Description : Lightweight client library for the MQTT protocol MQTT (Message Queuing Telemetry Transport) is a lightweight open messaging protocol that was developed for constrained environments such as M2M (Machine to Machine) and IoT (Internet of Things), where a small code footprint is required. MQTT is based on the Pub/Sub messaging principle of publishing messages and subscribing to topics. The protocol efficiently packs messages to minimize overhead. The wolfMQTT library is a client implementation of the MQTT written in C. It supports all Packet Types, all Quality of Service (QoS) levels 0-2 and supports SSL/TLS. This implementation provides support for MQTT v5.0 and is based on MQTT v3.1.1. Additionally, there is also client support for MQTT-SN (Sensor Network). - Supports MQTT specifications v3.1.1 and v5.0 - Support for MQTT-SN - Supports all client side packet types and protocol options - QoS Levels 0-2 (guaranteed delivery) - Message integrity, security are still available - Single threaded model and single message callback - Written in Native C89 with portability/compatibility in mind - Space conscience design (Compiled size is about 3.6kB) - User manual with build instructions, example overview, and API documentation - Example MQTT client implementations - Network interface is abstracted via callbacks for extensibility - Packet parsing encoding/decoding structured for custom use - Minimal external dependencies (strlen, memcpy, memset) - Detailed error checking/handling - Doxygen style inline documentation - Fewer than 1200 lines of well structured C code - Tested on multiple variants of MQTT broker servers, QoS levels 0-2 with/without TLS - FreeRTOS+TCP support wolfSSL has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Bug#983449: ITP: wolfssh -- Lightweight SSH Library
Package: wnpp Severity: wishlist Owner: Felix Lechner X-Debbugs-CC: debian-devel@lists.debian.org * Package name: wolfssh Version : 1.4.6 Upstream Author : John Safranek * URL : https://www.wolfssl.com/products/wolfssh/ * License : GPL-3+ Programming Lang: C Description : Lightweight SSH Library The wolfSSH library is a lightweight SSHv2 client and server library written in ANSI C and targeted for embedded, RTOS, and resource-constrained environments—primarily because of its small size, speed, and feature set. It is also often used in standard operating environments. Features: - SSH v2.0 (client and server) - Minimum footprint size of 33kB - Runtime memory usage between 1.4 and 2kB, not including a configurable receive buffer - Multiple Hashing Functions: SHA-1, SHA-2 (SHA-256, SHA-384, SHA-512), BLAKE2b - Block, Stream, and Authenticated Ciphers: AES (CBC, CTR, GCM, CCM), Camellia - Public Key Options: RSA, DH, EDH, NTRU - ECC Support (ECDH and ECDSA with curves: NISTP256, NISTP384, NISTP521 - Curve25519 and Ed25519 - Client authentication support (RSA key, password) - SCP support - SFTP support - Port forwarding support (client-side) - Simple API - PEM and DER certificate support - Hardware Cryptography Support: Intel AES-NI support, Intel AVX1/2, RDRAND, RDSEED, Cavium NITROX support, STM32F2/F4 hardware crypto support, Freescale CAU / mmCAU / SEC, Microchip PIC32MZ, support for MPLAB Harmony on PIC32 - Echoserver functionality - Interop Tested Against: OpenSSH, Tera term, PuTTY, Dropbear, Firezilla, BitVise wolfSSH is built for maximum portability and is generally very easy to compile on new platforms. wolfSSH has support for chipsets including ARM, Intel, Motorola, mbed, NXP/Freescale, Microchip (PIC32)/Atmel, STMicroelectronics (STM32F2/F4), Analog Devices, Texas Instruments, and more. I will maintain this package going forward. Kind regards Felix Lechner
Re: New service: https://debuginfod.debian.net
Hello Christoph, On Wed, 24 Feb 2021 at 11:06, Christoph Berg wrote: > Maybe the service should move to debuginfod.debian.*org* if it's going > to be a default. (Which I would like to see.) Yes, that is part of the plan, but it'll take some more time. Regards -- Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Re: New service: https://debuginfod.debian.net
Re: Sergio Durigan Junior > I would like to announce a new service that I have just configured for > Debian: https://debuginfod.debian.net. Very cool! > Currently, the elfutils and GDB packages in unstable and testing have > native support for using debuginfod. I will soon propose a change to > the elfutils package in order to make it be configured with our > debuginfod instance by default, so that users will be able to use the > service transparently. Maybe the service should move to debuginfod.debian.*org* if it's going to be a default. (Which I would like to see.) > For now, debuginfod.debian.net is serving debug information symbols for > the following Debian distributions: > > - unstable Can you add experimental? Christoph
Re: New service: https://debuginfod.debian.net
On 24.02.2021 05:53, Sergio Durigan Junior wrote: Hello there, I would like to announce a new service that I have just configured for Debian: https://debuginfod.debian.net. Congratulations. This seems like a great help for people debugging code. Eugen
