[systemd-devel] Antw: [EXT] Re: Additional Information for Ethernet

2021-12-09 Thread Ulrich Windl 
>>> Greg KH  schrieb am 09.12.2021 um 18:24 in
Nachricht :
> On Thu, Dec 09, 2021 at 03:13:42AM +, Spencer Ku (古世瑜) wrote:
>> Hi All,
>> We are developing the redfish of openbmc, and want to expose some Ethernet

> information through the redfish interface, like packet count, drop count. My

> goal is to calculate the bandwidth / drop package rate of the Ethernet. We 
> can get those counts from Ethernet driver 
> (/sys/class/net/{Ethernet_Name}/statistics), but as far as I know, there is

> no suitable d-bus to read those metrics.

I wonder: What's the problem with just reading that file?

>> 
>> 
>> 
>> My question is that: is it possible to create the new D-bus properties ( 
> like under the /org/freedesktop/{network}/network/{Ethernet_Name}), then
sync 
> the counts to that D-Bus?
> 
> Why not just use netlink for this?  I think it provides this information
> already as part of networking stats.  Have you looked into that?
> 
> thanks,
> 
> greg k-h

[systemd-devel] systemd prerelease 250-rc2

2021-12-09 Thread systemd tag bot 
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
tarball here:

https://github.com/systemd/systemd/archive/v250-rc2.tar.gz

NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Changes since the previous release:

* Support for encrypted and authenticated credentials has been added.
  This extends the credential logic introduced with v247 to support
  non-interactive symmetric encryption and authentication, based on a
  key that is stored on the /var/ file system or in the TPM2 chip (if
  available), or the combination of both (by default if a TPM2 chip
  exists the combination is used, otherwise the /var/ key only). The
  credentials are automatically decrypted at the moment a service is
  started, and are made accessible to the service itself in unencrypted
  form. A new tool 'systemd-creds' encrypts credentials for this
  purpose, and two new service file settings LoadCredentialEncrypted=
  and SetCredentialEncrypted= configure such credentials.

  This feature is useful to store sensitive material such as SSL
  certificates, passwords and similar securely at rest and only decrypt
  them when needed, and in a way that is tied to the local OS
  installation or hardware.

* systemd-gpt-auto-generator can now automatically set up discoverable
  LUKS2 encrypted swap partitions.

* The GPT Discoverable Partitions Specification has been substantially
  extended with support for root and /usr/ partitions for the majority
  of architectures systemd supports. This includes platforms that do
  not natively support UEFI, because even though GPT is specified under
  UEFI umbrella, it is useful on other systems too. Specifically,
  systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and
  Portable Services use the concept without requiring UEFI.

* The GPT Discoverable Partitions Specifications has been extended with
  a new set of partitions that may carry PKCS#7 signatures for Verity
  partitions, encoded in a simple JSON format. This implements a simple
  mechanism for building disk images that are fully authenticated and
  can be tested against a set of cryptographic certificates. This is
  now implemented for the various systemd tools that can operate with
  disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect,
  Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers.
  The PKCS#7 signatures are passed to the kernel (where they are
  checked against certificates from the kernel keyring), or can be
  verified against certificates provided in userspace (via a simple
  drop-in file mechanism).

* systemd-dissect's inspection logic will now report for which uses a
  disk image is intended. Specifically, it will display whether an
  image is suitable for booting on UEFI or in a container (using
  systemd-nspawn's --image= switch), whether it can be used as portable
  service, or attached as system extension.

* The system-extension.d/ drop-in files now support a new field
  SYSEXT_SCOPE= that may encode which purpose a system extension image
  is for: one of "initrd", "system" or "portable". This is useful to
  make images more self-descriptive, and to ensure system extensions
  cannot be attached in the wrong contexts.

* The os-release file learnt a new PORTABLE_PREFIXES= field which may
  be used in portable service images to indicate which unit prefixes
  are supported.

* The GPT image dissection logic in systemd-nspawn/systemd-dissect/…
  now is able to decode images for non-native architectures as well.
  This allows systemd-nspawn to boot images of non-native architectures
  if the corresponding user mode emulator is installed and
  systemd-binfmtd is running.

* systemd-logind gained new settings HandlePowerKeyLongPress=,
  HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and
  HandleHibernateKeyLongPress= which may be used to configure actions
  when the relevant keys are pressed for more than 5s. This is useful
  on devices that only have hardware for a subset of these keys. By
  default, if the reboot key is pressed long the poweroff operation is
  now triggered, and when the suspend key is pressed long the hibernate
  operation is triggered. Long pressing the other two keys currently
  does not trigger any operation by default.

* When showing unit status upda

[systemd-devel] [RFC] Invitation from the OpenSSF's Great MFA Distribution project

2021-12-09 Thread Robinson, Christopher 
Hello.  My name is CRob and I work with the Developer Best Practices Working 
Group of the Linux 
Foundation's Open Source Security Foundation (OpenSSF) "Great Multi-Factor 
Authentication (MFA) Distribution 
Project".

We'd like to give your project free MFA hardware tokens from Google and GitHub, 
for use by your maintainers. We'd especially like to give them to any of your 
maintainers who aren't already using any. Our goal is to help improve the 
security of open source software (OSS)/Free Software projects. For example, 
these tokens can counter attacks that release source code updates and/or 
packages using stolen passwords.

By 2021-12-20 and preferably much sooner, please let me know:

  1.  If you want any tokens, and if so...
  2.  How many Titan tokens from Google (up to 5)
  3.  How many Yubikey tokens from GitHub (up to 5)
  4.  The private email address to send codes to (this email must not go to the 
public, as these are use-once codes that can be used to get the tokens)
  5.  If you could use more, how many more.

We would send you coupon codes and validation codes to the private email 
address. You would then distribute those codes to the maintainers you choose. 
The recipients would use the coupon codes and validation codes to "buy" the 
tokens from the Google Store and/or GitHub Shop, who would ship the tokens 
directly to recipients. These codes are use-once, so make sure you can keep the 
codes private until they're used by the intended person.

Important: The Google coupon codes must be used by 2021-12-31 on the Google 
Store or they expire.

How can you trust us? You don't need to. You would get the MFA tokens from 
Google and GitHub; we're simply offering codes to make them no-cost. We'll 
provide some documentation on how to use them, but you don't need to use our 
documents.

To qualify, each token recipient must:

  1.  Be a maintainer or contributor to this critical open source software 
(OSS) project, or to another OSS project that this project depends on (the 
dependency may be indirect).
  2.  Try to use an MFA token once they receive the token. We'd like recipients 
to use MFA tokens from then on, but at least try.
  3.  Not reuse the token between different people (the token must not be 
shared).
  4.  Consider providing feedback to us (so we can try to fix problems).

We also need each project that receives coupon codes and/or validation codes to 
tell us these numbers (preferably within 30 days of getting the codes):

  1.  How many tokens did you distribute from just Google? From just GitHub?
  2.  How many people received tokens from just Google? From just GitHub? From 
both?
  3.  How many people didn't have hardware tokens they used for OSS who 
received tokens from just Google? From just GitHub? From both?

We ask for this information so we can tell others some simple measures of 
success. We don't need nor want the names of any individuals participating. 
It's fine to ask the people who got the codes for that information and provide 
a best-effort summary.

The MFA tokens are shipped from the US. They can be shipped internationally, 
but there are various limitations on where each can be shipped.

In particular, we can't ship somewhere if that is forbidden (sanctioned) under 
US law. So at this time we are unable to ship to individuals in China, 
Afghanistan, Russia, Ukraine, North Korea, Iran, Sudan, and Syria. Sorry about 
that. See the Google and GitHub sites for more shipping information. More 
sanction information is 
available.

For more information including how-tos and other setup information can be found 
at the "Great Multi-Factor Authentication (MFA) Distribution Project" 
site.


Cheers,

CRob
Director of Security Communications
Intel Product Assurance and Security

Re: [systemd-devel] Additional Information for Ethernet

2021-12-09 Thread Greg KH 
On Thu, Dec 09, 2021 at 03:13:42AM +, Spencer Ku (古世瑜) wrote:
> Hi All,
> We are developing the redfish of openbmc, and want to expose some Ethernet 
> information through the redfish interface, like packet count, drop count. My 
> goal is to calculate the bandwidth / drop package rate of the Ethernet. We 
> can get those counts from Ethernet driver 
> (/sys/class/net/{Ethernet_Name}/statistics), but as far as I know, there is 
> no suitable d-bus to read those metrics.
> 
> 
> 
> My question is that: is it possible to create the new D-bus properties ( like 
> under the /org/freedesktop/{network}/network/{Ethernet_Name}), then sync the 
> counts to that D-Bus?

Why not just use netlink for this?  I think it provides this information
already as part of networking stats.  Have you looked into that?

thanks,

greg k-h

[systemd-devel] systemd prerelease 250-rc1

2021-12-09 Thread systemd tag bot 
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the 
tarball here:

https://github.com/systemd/systemd/archive/v250-rc1.tar.gz

NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:

https://github.com/systemd/systemd/issues/new?template=Bug_report.md

Changes since the previous release:

* Support for encrypted and authenticated credentials has been added.
  This extends the credential logic introduced with v247 to support
  non-interactive symmetric encryption and authentication, based on a
  key that is stored on the /var/ file system or in the TPM2 chip (if
  available), or the combination of both (by default if a TPM2 chip
  exists the combination is used, otherwise the /var/ key only). The
  credentials are automatically decrypted at the moment a service is
  started, and are made accessible to the service itself in unencrypted
  form. A new tool 'systemd-creds' encrypts credentials for this
  purpose, and two new service file settings LoadCredentialEncrypted=
  and SetCredentialEncrypted= configure such credentials.

  This feature is useful to store sensitive material such as SSL
  certificates, passwords and similar securely at rest and only decrypt
  them when needed, and in a way that is tied to the local OS
  installation or hardware.

* systemd-gpt-auto-generator can now automatically set up discoverable
  LUKS2 encrypted swap partitions.

* The GPT Discoverable Partitions Specification has been substantially
  extended with support for root and /usr/ partitions for the majority
  of architectures systemd supports. This includes platforms that do
  not natively support UEFI, because even though GPT is specified under
  UEFI umbrella, it is useful on other systems too. Specifically,
  systemd-nspawn, systemd-sysext, systemd-gpt-auto-generator and
  Portable Services use the concept without requiring UEFI.

* The GPT Discoverable Partitions Specifications has been extended with
  a new set of partitions that may carry PKCS#7 signatures for Verity
  partitions, encoded in a simple JSON format. This implements a simple
  mechanism for building disk images that are fully authenticated and
  can be tested against a set of cryptographic certificates. This is
  now implemented for the various systemd tools that can operate with
  disk images, such as systemd-nspawn, systemd-sysext, systemd-dissect,
  Portable services/RootImage=, systemd-tmpfiles, and systemd-sysusers.
  The PKCS#7 signatures are passed to the kernel (where they are
  checked against certificates from the kernel keyring), or can be
  verified against certificates provided in userspace (via a simple
  drop-in file mechanism).

* systemd-dissect's inspection logic will now report for which uses a
  disk image is intended. Specifically, it will display whether an
  image is suitable for booting on UEFI or in a container (using
  systemd-nspawn's --image= switch), whether it can be used as portable
  service, or attached as system extension.

* The system-extension.d/ drop-in files now support a new field
  SYSEXT_SCOPE= that may encode which purpose a system extension image
  is for: one of "initrd", "system" or "portable". This is useful to
  make images more self-descriptive, and to ensure system extensions
  cannot be attached in the wrong contexts.

* The os-release file learnt a new PORTABLE_PREFIXES= field which may
  be used in portable service images to indicate which unit prefixes
  are supported.

* The GPT image dissection logic in systemd-nspawn/systemd-dissect/…
  now is able to decode images for non-native architectures as well.
  This allows systemd-nspawn to boot images of non-native architectures
  if the corresponding user mode emulator is installed and
  systemd-binfmtd is running.

* systemd-logind gained new settings HandlePowerKeyLongPress=,
  HandleRebootKeyLongPress=, HandleSuspendKeyLongPress= and
  HandleHibernateKeyLongPress= which may be used to configure actions
  when the relevant keys are pressed for more than 5s. This is useful
  on devices that only have hardware for a subset of these keys. By
  default, if the reboot key is pressed long the poweroff operation is
  now triggered, and when the suspend key is pressed long the hibernate
  operation is triggered. Long pressing the other two keys currently
  does not trigger any operation by default.

* When showing unit status upda

[systemd-devel] [RFC] Invitation from the OpenSSF's Great MFA Distribution project

2021-12-09 Thread Robinson, Christopher 
Hello!  My name is CRob and I work with the Developer Best Practices Working 
Group of the Linux 
Foundation's Open Source Security Foundation (OpenSSF) "Great Multi-Factor 
Authentication (MFA) Distribution 
Project".
We'd like to give your project free MFA hardware tokens from Google and GitHub, 
for use by your maintainers. We'd especially like to give them to any of your 
maintainers who aren't already using any. Our goal is to help improve the 
security of open source software (OSS)/Free Software projects. For example, 
these tokens can counter attacks that release source code updates and/or 
packages using stolen passwords.
By 2021-12-20 and preferably much sooner, please let me know:

  1.  If you want any tokens, and if so...
  2.  How many Titan tokens from Google (up to 5)
  3.  How let Yubikey tokens from GitHub (up to 5)
  4.  The private email address to send codes to (this email must not go to the 
public, as these are use-once codes can be used to get the tokens)
  5.  If you could use more, how many more.
We would send you coupon codes and validation codes to the private email 
address. You would then distribute those codes to the maintainers you choose. 
The recipients would use the coupon codes and validation codes to "buy" the 
tokens from the Google Store and/or GitHub Shop, who would ship the tokens 
directly to recipients. These codes are use-once, so make sure you can keep the 
codes private until they're used by the intended person.
Important: The Google coupon codes must be used by 2021-12-31 on the Google 
Store or they expire.
How can you trust us? You don't need to. You would get the MFA tokens from 
Google and GitHub; we're simply offering codes to make them no-cost. We'll 
provide some documentation on how to use them, but you don't need to use our 
documents.
To qualify, each token recipient must:

  1.  Be a maintainer or contributor to this critical open source software 
(OSS) project, or to another OSS project that this project depends on (the 
dependency may be indirect).
  2.  Try to use an MFA token once they receive the token. We'd like recipients 
to use MFA tokens from then on, but at least try.
  3.  Not reuse the token between different people (the token must not be 
shared).
  4.  Consider providing feedback to us (so we can try to fix problems).
We also need each project that receives coupon codes and/or validation codes to 
tell us these numbers (preferably within 30 days of getting the codes):

  1.  How many tokens did you distribute from just Google? From just GitHub?
  2.  How many people received tokens from just Google? From just GitHub? From 
both?
  3.  How many people didn't have hardware tokens they used for OSS who 
received tokens from just Google? From just GitHub? From both?
We ask for this information so we can tell others some simple measures of 
success. We don't need nor want the names of any individuals participating. 
It's fine to ask the people who got the codes for that information and provide 
a best-effort summary.
The MFA tokens are shipped from the US. They can be shipped internationally, 
but there are various limitations on where each can be shipped.
In particular, we can't ship somewhere if that is forbidden (sanctioned) under 
US law. So at this time we are unable to ship to individuals in China, 
Afghanistan, Russia, Ukraine, North Korea, Iran, Sudan, and Syria. Sorry about 
that. See the Google and GitHub sites for more shipping information. More 
sanction information is 
available.
For more information including how-tos and other setup information can be found 
at the "Great Multi-Factor Authentication (MFA) Distribution Project" 
site.


Cheers,

CRob
Director of Security Communications
Intel Product Assurance and Security

[systemd-devel] Additional Information for Ethernet

2021-12-09 Thread 古世瑜 
Hi All,
We are developing the redfish of openbmc, and want to expose some Ethernet 
information through the redfish interface, like packet count, drop count. My 
goal is to calculate the bandwidth / drop package rate of the Ethernet. We can 
get those counts from Ethernet driver 
(/sys/class/net/{Ethernet_Name}/statistics), but as far as I know, there is no 
suitable d-bus to read those metrics.



My question is that: is it possible to create the new D-bus properties ( like 
under the /org/freedesktop/{network}/network/{Ethernet_Name}), then sync the 
counts to that D-Bus?

It can really help us to get the metrics easily via redfish.

The detail discussions in openbmc upstream please refer to the link: 
https://lists.ozlabs.org/pipermail/openbmc/2021-December/028422.html
We are willing to see any suggestions, thanks!

Sincerely,
Spencer Ku