publish entire blog content to feed

i'm -1 here as it renders pretty poorly
Full render of rss feed underneath

<title>The Python Package Index</title>
<description>The official blog of the Python Package Index</description>
<link>http://<IP_ADDRESS>:8000/</link>
<atom:link href="http://<IP_ADDRESS>:8000/feed_rss_created.xml" rel="self" type="application/rss+xml" />

<docs>https://github.com/pypi/warehouse</docs>
<language>en</language>

<pubDate>Wed, 31 May 2023 01:37:27 -0000</pubDate>
<lastBuildDate>Wed, 31 May 2023 01:37:27 -0000</lastBuildDate>
<ttl>1440</ttl>

<generator>MkDocs RSS plugin - v1.6.0</generator>

<image>
  <url>https://blog.pypi.org/assets/logo.png</url>
  <title>The Python Package Index</title>
  <link>http://<IP_ADDRESS>:8000/</link>
</image>

<item>
  <title>Reducing Stored IP Data in PyPI</title>

  <author>Mike Fiedler</author>

  <category>security</category>

  <category>transparency</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#security" class="blogging-tag"><code>#security</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#transparency" class="blogging-tag"><code>#transparency</code></a>

</div>

Hi there! I'm Mike, the newest member of the PyPI admin team. Nice to meet you!

TL;DR

We've been working on reducing the amount of IP address data we store,
and we're making progress.

What's this about?

If you've read some of the other blogs here, you may have noticed that
we've been working on a number of security and privacy improvements.

A few months ago we started exploring what it would take
to remove the concept of IP addresses from our stack,
and retain the ability to safely manage the platform.

Some places of where IP data was historically used:

web access logs

user events (login,. logout, password reset, et al)

project events (creation, new releases, new file uploads, yanks, et al)

organization/team membership events (new!)

journal entries (private to PyPI admins)

Security is a spectrum - where on one extreme, it's the wild west, no security.
On the other extreme, everything is locked down, impossible to use.
We constantly have to balance the needs and desires of our users
with the needs of running a sustainable, trusted platform.

A similar mindset can be applied to privacy - where we must strike the balance
between providing a manageable service, and protecting the privacy of our users.

The two main approaches we've pursued in the short term are:

Evaluate whether we need to store IP data at all

Whenever possible, use alternatives to IP data

I'll provide a couple of examples demonstrating the above.

Do we need the IP data?

As we evaluated the different places we stored IP data,
we learned that our Journal entries (similar to an append-only transaction log)
were never exposed beyond admin users, and even then, used for admin display only.

We never share that via API, or used it for operational purposed.
So we audited the code, removed calls to stop writing the column, and dropped it.

Woohoo!

Other places where we currently still need IP data include rate limiting,
and fallbacks until we have backfilled the IP data with hashes and geo data.
Our modern approach has evolved from using the IP data at display time to find
the relevant geo data, to storing the geo data directly in the database.

Another use case is for handling abuse - we need to be able to identify
the source of abuse, and take action to prevent it.
We're thinking about how to manage that without storing IP data,
but we're not there yet.

Alternatives to IP data

For the other places where we stored IP data,
we asked ourselves - could we use an alternative?

We can't store what we don't see, so we explored what we could do to
reduce the amount of IP data we see.

Pretty much every request to PyPI is served via our CDN partner, Fastly.
They provide a number of features, including the ability to
<a href="https://docs.fastly.com/en/guides/adding-or-modifying-headers-on-http-requests-and-responses">add custom headers.
We leverage this ability already for a number of things,
like informing the warehouse code of the inbound encoding of the request or language.

We explored whether we could use this to add a hash of the IP address,
and use that instead of the IP address itself.
Fastly can also provide some basic geographic info about the IP address,
which served our purpose of showing the user where they had connected from.

Using this approach, we have Fastly pass along an already-hashed IP address,
as well as the geographic data, to our backend, and store those for later use.

Another spot we identified was web access logs.
We don't need real IP addresses there,
as we rarely use them for anything other than low-level debugging,
so a stable, hashed value serves the purpose of correlating requests.

For the requests that Fastly doesn't serve, we're already hashing the IP address
ourselves prior to storage, so we could "see" the IP address briefly,
but we try to avoid storing it.
We don't get get the geo data for these requests,
we're thinking of creative and sustainable solutions already.

Questions and Answers

I tried to think up some questions you might have, and answer them here.
If you have more, please feel free to reach out to us!

Q: Is a hashed IP address secure?

A: It's more secure than a plain IP address, for sure.
We apply a <a href="https://en.wikipedia.org/wiki/Salt_(cryptography)">salt</a> (known value)
to the IP address before hashing it.
It's not a perfect solution, but it's a step in the right direction.

The hash is non-reversible, but since the known address space is relatively small,
it's possible to brute force the hash to determine the original IP address.
By applying a salt, we require someone to possess both the salt
and the hashed IP addresses to brute force the value.
Our salt is not stored in the database while the hashed IP addresses are,
we protect against leaks revealing this information.

Q: Is this a response to the subpoenas?

A: No, we started exploring this <a href="https://github.com/pypi/warehouse/issues/8158">back in 2020,
with a long term goal to increase end-user security,
while retaining the ability to effectively steer the platform.
We picked it up recently as we explored our CDN partner's options for geo IP data.

Q: Are we done?

A: Nope! Security is an ongoing journey,
and we're making strong strides to accomplish this goal.
We still have some work to do to replace IP data in our models,
after we've backfilled our models with the hashed IP data and relevant geo data,
and clean up some of the code.

Q: What's next?

A: I can't predict every future step we're likely to take,
but some things we're considering:

Reevaluate the need for IP data in Event history forever,
remove it after a period of time

Explore whether we can use a CDN for all requests

Determine if there's a better mechanism than Journal Entries, and replace them

We believe the steps we're taking are in the right direction,
and we're excited to share our progress with you.
Hopefully this enriches your understanding of the work we're doing,
in support of maintaining a secure, trusted platform.

Thanks for reading!

Mike Fiedler is a PyPI administrator
and maintainer of the Python Package Index since 2022.

http://<IP_ADDRESS>:8000/posts/2023-05-26-reducing-stored-ip-data/
Fri, 26 May 2023 15:00:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-05-26-reducing-stored-ip-data/</guid>

</item>

<item>
  <title>Securing PyPI accounts via Two-Factor Authentication</title>

  <author>Donald Stufft</author>

  <category>2fa</category>

  <category>security</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#security" class="blogging-tag"><code>#security</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#2fa" class="blogging-tag"><code>#2fa</code></a>

</div>

One of the key security promises that PyPI makes is that when you're downloading
something, that only the people associated with that project are going to be able
to upload, delete, or otherwise modify a project. That when you look at that
project and see that it is owned by someone that you trust, that you can be
assured that nobody else is making changes to that package on PyPI.

This promise is predicated on the security of each and every individual account
on PyPI used to create and maintain a Python project. In the past we've taken
steps to safeguard these accounts by
<a href="https://caremad.io/posts/2018/08/pypi-compromised-passwords/">blocking compromised passwords, strong 2FA support using
<a href="https://github.com/pypi/warehouse/pull/5567">TOTP</a> and
<a href="https://github.com/pypi/warehouse/pull/5795">WebAuthN</a>,
<a href="https://pypi.org/help/#apitoken">support for API tokens with offline attenuation,
<a href="https://pypi.org/security-key-giveaway/">enrolling the most downloaded projects into mandatory 2FA,
and <a href="https://blog.pypi.org/posts/2023-04-20-introducing-trusted-publishers/">enabling short lived tokens for upload.

Today, as part of that long term effort to secure the Python ecosystem, we are
announcing that every account that maintains any project or organization
on PyPI will be required to enable 2FA on their account by the end of 2023.

Between now and the end of the year, PyPI will begin gating access to certain
site functionality based on 2FA usage. In addition, we may begin selecting
certain users or projects for early enforcement.

What can I do to prepare?

The most important things you can do to prepare are to enable 2FA for your
account as soon as possible, either with a
<a href="https://pypi.org/help/#utfkey">security device (preferred) or an
<a href="https://pypi.org/help/#totp">authentication app and to switch to using either
<a href="https://docs.pypi.org/trusted-publishers/">Trusted Publishers (preferred) or
<a href="https://pypi.org/help/#apitoken">API tokens to upload to PyPI.

Why Use 2FA?

Account takeover attacks typically stem from someone using an insecure password:
perhaps it was easy to guess, or it was reused and appeared in a breach. With
that insecure password, an attacker is able to gain control over a maintainers
account and begin to take actions as if they were that user.

This is particularly problematic on a site like PyPI, where the actions that a
person can take include releasing software that might be used by people world
wide, allowing an attacker to install and execute software on unsuspecting
user's computers. <a href="https://python-security.readthedocs.io/pypi-vuln/index-2022-05-24-ctx-domain-takeover.html">Account takeover attacks have been previously used to
compromise PyPI users in this
way.

Two-factor authentication immediately neutralizes the risk associated with a
compromised password.  An account with
access to the most downloaded project on PyPI can be used to attack far more
people than an account with access to the least downloaded project.

However, it only takes one compromised project in someone's dependency set to
compromise their computer. The attacker doesn't care if they get you from a
widely used or a niche project, just that they got you. Even worse, once
compromised, an attacker can extend that attack to attack other systems,
including other projects on PyPI that the now compromised person maintains.

Given that it only takes one compromised project, no matter how many downloads
it gets [^1], to compromise someone we want to ensure that every project is
being protected by 2FA.

On the flipside, an account without access to any project cannot be used to
attack anyone [^2] so it is a very low value target.

We recognize that enabling 2FA for an account imposes a non zero cost both for
the owner of that account and for PyPI [^3], so forcing that on accounts that
cannot affect anyone but themselves is not an effective use of limited
resources. In addition, from a practical view, the standard 2FA flow that most
people are used to and that PyPI implements also involves adding a 2FA token
to an existing account rather than forcing it to be part of the registration
flow.

Our expectation is that for users who currently are not a project maintainer or
organization member, the ultimate experience will be whenever they attempt to
take some action that would require them to add 2FA (creating a new project,
accepting an invite, making an organization, etc) they will be prompted to add
2FA to their account before they can proceed.

Why now?

The direction of many projects in or serving the Open Source community in the
last 5-10 years has been an increasing focus on supply chain security,
preventing attacks that are being delivered through the "supply chain", namely
the services and tooling used to create and consume software.

In July of 2022, we announced
<a href="https://pypi.org/security-key-giveaway/">a security key giveway in conjunction
with a plan to begin mandating 2FA for the top 1% of projects on PyPI by download
count.

The initial announcement of that mandate to the top 1%
of projects and the related giveaway was met with mixed reactions, ranging from
people applauding the effort to people deciding to distribute their code on
places other than PyPI. We planned to limit this to the projects in the top 1%
of downloads because those are likely he highest value targets for an attacker,
and because we were concerned about the impact of such a mandate on both the
maintainers of projects on PyPI, and on the support burden of the PyPI team
itself.

At that time last year, we did not have any plans or expectations on widening
our net of users that would fall under that mandate, other than would occur
naturally as projects rose in popularity to be part the top 1%.

However, in the year since then a few things have changed.

We've gotten a lot more confident in our 2FA implementation and in what the
impact to enabling it is for both people publishing to PyPI, and to the PyPI
team itself.

We've shipped features like
<a href="https://docs.pypi.org/trusted-publishers/">Trusted Publishing that help
remove some of the overheard of 2FA has on publishing (by far the most common
action users do).

GitHub has furthered it's
<a href="https://github.blog/2022-05-04-software-security-starts-with-the-developer-securing-developer-accounts-with-2fa/">plans to mandate 2FA for all contributors
on their platform, making more people already (or soon will be) prepared to cope
with the requirements of having 2FA.

The PSF has received funding to hire a
<a href="https://blog.pypi.org/posts/2023-05-09-announcing-pypi-safety-and-security-engr-role/">PyPI Safety and Security Engineer.
While the role is not meant to purely handle support requests, having
dedicated focus on the overall security posture, as well as the
implementation specifics will improve PyPI as a whole for both
users and project maintainers, and will help alleviate some of the
pressures on PyPI's volunteers.

The workload to support end users relies heavily on a very small group of
volunteers. When an user account report is seen by our trusted admins, we have
to take time to properly investigate. These are often reported as an emergency,
red-alert-level urgency. By mandating 2FA for project maintainers, the
likelihood of account takeovers drop significantly, reserving the emergency
status for truly extraordinary circumstances. Account recovery becomes part of
normal routine support efforts instead of admin-level urgency.

All of these together help lead us to the conclusion that we can widen our
mandate to all project maintainers on PyPI, while minimizing the impact on
both project maintainers and PyPI administrators, and to do so in a way that
improves the sustainability of PyPI and the wider Python ecosystem.

Isn't supply chain security a corporate concern?

There are some people who believe that efforts to improve supply chain security
benefits only corporate or business users, and that individual developers should
not be asked to take on a uncompensated burden for their benefit.

We believe this is shortsighted.

A compromise in the supply chain can be used to attack individual developers the
same as it able to attack corporate and business users. In fact, we believe
that individual developers, are in a more vulnerable position than corporate
and business users. While businesses are generally able to hire staff and devote
resources to vetting their dependencies, individual developers generally are
not, and must expend their own limited free time to do so [^4].

To make matters worse for the individual, in the case of a compromise a business
is more likely going to have experts available to them to detect and remediate
the compromise, while the individual has to do this on their own. At the extreme
ends, businesses often have insurance to compensate them for any losses incurred
while the individual almost always does not.

We recognize that supply chain security effects everyone, no matter how big
or how small they are, and we are dedicated to protecting all our users.

Donald Stufft is a PyPI administrator and maintainer of the Python Package Index since 2013.

[^1]: Technically a project with 0 downloads is effectively the same as a
non-existent project, but it's easier to draw the line between
non-existent and existent than it is to draw the line between 0 and 1
downloads. This is particularly true on PyPI, where a large network of
mirrors and scanners mean that no projects truly get downloaded exactly
0 times.
[^2]: Except maybe the account owner themselves, by denying them access to their
account.
[^3]: For end users it forces them to purchase some kind of hardware token OR
to use some sort of TOTP application. In both cases it forces them to keep
track of something else besides their password and changes the login flow
from what they are used to. For PyPI it increases the chance that someone
may get locked out of their account, requiring intervention by administrators.
[^4]: Not for nothing, but PyPI is also an Open Source project, run largely by
volunteers, and cleaning up after a compromise on PyPI is something that
affects those volunteers significantly.

http://<IP_ADDRESS>:8000/posts/2023-05-25-securing-pypi-with-2fa/
Thu, 25 May 2023 00:00:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-05-25-securing-pypi-with-2fa/</guid>

</item>

<item>
  <title>PyPI was subpoenaed</title>

  <author>Ee Durbin</author>

  <category>compliance</category>

  <category>transparency</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#transparency" class="blogging-tag"><code>#transparency</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#compliance" class="blogging-tag"><code>#compliance</code></a>

</div>

In March and April 2023, the Python Software Foundation (PSF)
received three (3) subpoenas for PyPI user data.
All three subpoenas were issued by the United States Department of Justice.
The PSF was not provided with context on the legal circumstances surrounding these subpoenas.
In total, user data related to five (5) PyPI usernames were requested.

The data request was:

"Names (including subscriber names, user names, and screen names);"

"Addresses (including mailing, residential addresses, business addresses, and email addresses);"

"Connection records;"

"Records of session times and durations, and the temporarily assigned network address (such as Internet Protocol addresses) associated with those sessions;"

"Length of service (including start date) and type of services utilized;"

"Telephone or instrument numbers (including the registration Internet Protocol address);"

"Means and source of payment of any such services (including any credit card or bank account number) and billing records;"

"Records of all Python Package Index (PyPI) packages uploaded by..." given usernames

"IP download logs of any Python Package Index (PyPI) packages uploaded by..." given usernames

The privacy of PyPI users is of utmost concern to PSF and the PyPI Administrators,
and we are committed to protecting user data from disclosure whenever possible.
In this case, however, PSF determined with the advice of counsel that
our only course of action was to provide the requested data.
I, as Director of Infrastructure of the Python Software Foundation,
fulfilled the requests in consultation with PSF's counsel.

We have waited for the string of subpoenas to subside, though we were committed
from the beginning to write and publish this post as a matter of transparency,
and as allowed by the lack of a non-disclosure order associated with the
subpoenas received in March and April 2023.

Next Steps

PyPI and the PSF are committed to the freedom, security, and privacy of our users.

This process has offered time to revisit our current data and privacy standards,
which are minimal, to ensure they take into account the varied interests of
the Python community.
Though we collect very little personal data from PyPI users,
any unnecessarily held data are still subject to these kinds of requests
in addition to the baseline risk of data compromise via malice or operator error.

As a result we are currently developing new data retention and disclosure policies.
These policies will relate to
our procedures for future government data requests,
how and for what duration we store personally identifiable information such as
user access records,
and policies that make these explicit for our users and community.

Please continue to watch this blog for related announcements as policies
are finalized, published, and implemented.

Details

In order to provide as much transparency as possible,
the following will detail the shape of and extent of
the data that was contained in the responses to these subpoenas.

We will not be releasing the usernames involved publicly
or to the users themselves.

1) Names (including subscriber names, user names, and screen names);

These were confirmed via our database records

sql
select id, username, name from users where username = '{USERNAME}';

Returning:
id       | UUID for USERNAME
username | PyPI username
name     | Display name for user

And are also publicly available at https://pypi.org/user/{USERNAME}/</code>.</p>

PyPI allows users to delete their accounts.

PyPI does not allow for the username field to be changed without admin intervention,
and no such intervention has occurred for the users in question.
If they had, we would have provided records of those changes.

PyPI does allow for user to update their display names
and keeps no record of the history of these changes.

2) Addresses (including mailing, residential addresses, business addresses, and email addresses);

PyPI only stores email addresses for individual users. No physical addresses are stored.
Organization accounts who have signed up for billing (not yet live)
will be required to provide a billing address that validates to their payment method.

These were sourced from our database records and is private to PyPI.

sql
select email, user_id from user_emails where user_id ='{UUID for USERNAME}';

Returning:
email   | An email address
user_id | UUID for USERNAME

PyPI allows for users to add and remove email addresses without admin intervention.
Records of these changes are kept, and no such changes were observed in our records for
the usernames in question.
If they had, we would have provided records of those changes.

3. Connection records

3a. Project events

PyPI retains records of all changes to projects on the index,
and has since 2002-11-01 17:11:36 UTC.

These were confirmed via our database records

sql
select * from journals where submitted_by='{USERNAME}' order by submitted_date;

Returning:
id             | An auto incrementing integer representing the "Serial"
name           | Name of a PyPI Project
version        | Version of a PyPI Release if relevant
action         | Description of the action taken against the Project/Release
submitted_date | ISO-8601 datetime in UTC
submitted_by   | PyPI Username
submitted_from | IP Address

and with the exception of the submitted_by (PyPI username)
and submitted_from (IP Address) columns
are publicly available via our <a href="https://warehouse.pypa.io/api-reference/xml-rpc.html#changelog-since-with-ids-false">XMLRPC API.

3b. User events

PyPI retains records of critical user events including
account creation, emails sent, email address changes, logins, and login failures.
See <a href="https://github.com/pypi/warehouse/blob/9738ebb2ffcee91a935a6a11b224575aaf02a878/warehouse/events/tags.py#L61-L106">this list
for the comprehensive set of events recorded.

These were sourced from our database records

sql
select * from user_events where source_id = '{UUID for USERNAME}' order by time desc;

Returning:
id                | UUID of the event
source_id         | UUID for USERNAME
tag               | EventTag
time              | ISO-8601 datetime in UTC
ip_address_string | IP Address
additional        | JSONB metadata about the event
ip_address_id     | UUID of associated IPAddress object

and are private to PyPI.

4. Records of session times and durations, and the temporarily assigned network address (such as Internet Protocol addresses) associated with those sessions;

PyPI does not record session durations.

Session creation (Login) times were provided as a synopsis of the data in 3b.

Sessions are not created for uploads, but the associated login events
for project uploads were provided as a synopsis of the data in 3a.

5. Length of service (including start date) and type of services utilized;

PyPI retains records of the date that a user account was created,
as well as the last time it was successfully logged in by any method
(web UI or command line tool for upload).

sql
select date_joined, last_login from users where username =  {USERNAME}

Returning:
date_joined | ISO-8601 datetime in UTC
last_login  | ISO-8601 datetime in UTC

These were sourced from our database records and are private to PyPI.

Types of service utilized are "standard" to PyPI and include the ability to
create projects, releases, and distribution files for downloads.

6. Telephone or instrument numbers (including the registration Internet Protocol address);

A synopsis of all IP Addresses for each username from previous records were shared.

These were sourced from our database records and are private to PyPI.

7. Means and source of payment of any such services (including any credit card or bank account number) and billing records;

PyPI has no cost to use for individual users
and no such payment records or billing records exist.

8. Records of all Python Package Index (PyPI) packages uploaded by the given usernames

A list of all past and any current projects associated with each username was provided.

These were sourced from our database records and for past projects, are private to PyPI.

9. IP download logs of any Python Package Index (PyPI) packages uploaded by the given usernames

PyPI does not retain download logs for packages which include IP addresses.
Download logs are processed by a pipeline which includes GeoIP information reported by our CDN only.

These records were sourced from the <a href="https://warehouse.pypa.io/api-reference/bigquery-datasets.html">Google BigQuery Public dataset with the following queries:

sql
SELECT * FROM bigquery-public-data.pypi.file_downloads
WHERE project IN ({LIST OF PROJECT NAMES FROM 8})
AND timestamp > '{START OF PERIOD IN QUESTION}';

Ee Durbin is the Director of Infrastructure at
the Python Software Foundation.
They have been contributing to keeping PyPI online, available, and
secure since 2013.

http://<IP_ADDRESS>:8000/posts/2023-05-24-pypi-was-subpoenaed/
Wed, 24 May 2023 13:12:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-05-24-pypi-was-subpoenaed/</guid>

</item>

<item>
  <title>Removing PGP from PyPI</title>

  <author>Donald Stufft</author>

  <category>security</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#security" class="blogging-tag"><code>#security</code></a>

</div>

If you are someone who is currently uploading signatures, your package uploads will
continue to succeed, but any PGP signatures will be silently ignored. If you are
someone who is currently downloading PGP signatures, existing signatures
SHOULD continue to be available [^1], but no new signatures will be made available.
The related API fields such as has_sig have all been hardcoded to always be
False.

Historically, PyPI has supported uploading PGP signatures alongside the release
artifacts in an attempt to provide some level of package signing. However, the
approach used had long standing,
<a href="https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/">documented issues
which had previously lead us to deemphasize the support
for PGP signatures over time by removing them from the PyPI web user interface.

PyPI has continued to support uploading these signatures in the hope that there
might be some systems out there that found them useful. Recently though,
<a href="https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI-worse-than-useless">an examination of the signatures on PyPI
has revealed to us that the current support for PGP signatures is not proving useful.

In the last 3 years, about 50k signatures had been uploaded to PyPI by 1069
unique keys. Of those 1069 unique keys, about 30% of them were not discoverable
on major public keyservers, making it difficult or impossible to meaningfully
verify those signatures. Of the remaining 71%, nearly half of them were unable
to be meaningfully verified at the time of the audit (2023-05-19) [^2].

In other words, out of all of the unique keys that had uploaded signatures to
PyPI, only 36% of them were capable of being meaningfully verified [^3] at the
time of audit. Even if all of those signatures uploaded in that 3 year period
of time were made by one of those 36% of keys that are able to be meaningfully
verified, that would still represent only 0.3% of all of those files.

Given all of this, the continued support of uploading PGP signatures to PyPI is
no longer defensible. While it doesn't represent a massive operational burden
to continue to support it, it does require any new features that touch the
storage of files to be made aware of and capable of handling these PGP
signatures, which is a non zero cost on the maintainers and contributors of
PyPI.

Donald Stufft is a PyPI administrator and maintainer of the Python Package Index since 2013.

[^1]: For now, but they may be removed in the future.
[^2]: These could be because the original signature was made incorrectly and
never had a binding signature to a associated key identity, or because
the signature was present but had since expired.
[^3]: We use meaningfully verified to mean that the signature was valid and the
key that made it was not expired and had binding identify information that
could tell us if this key was the correct key.

http://<IP_ADDRESS>:8000/posts/2023-05-23-removing-pgp/
Tue, 23 May 2023 00:00:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-05-23-removing-pgp/</guid>

</item>

<item>
  <title>Announcing the PyPI Safety & Security Engineer role</title>

  <author>Ee Durbin</author>

  <category>hiring</category>

  <category>security</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#security" class="blogging-tag"><code>#security</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#hiring" class="blogging-tag"><code>#hiring</code></a>

</div>

We are pleased to announce
Amazon Web Services (AWS)
as the inaugural Security Sponsor for PyPI,
investing $144,000 over one year
to fund key enhancements to PyPI infrastructure and operations,
including the creation of a new “PyPI Safety & Security Engineer” role.

This role builds on our existing long term partnership with AWS
as one of the top sponsors of the Python Software Foundation for the last five years,
which has included in-kind donations of cloud computing infrastructure
and services to support PyPI.
The role will complement our previously announced role for a
<a href="https://pyfound.blogspot.com/2023/01/the-psf-is-hiring-security-developer-in.html">PSF Security Developer in Residence
and will work closely with the person hired for that role (to be announced soon).

This funding also builds on
<a href="https://dustingram.com/articles/2021/04/14/powering-the-python-package-index-in-2021/#project-funding">previously successful project-focused funding efforts,
such as the 2018 full-stack rewrite of PyPI,
the introduction of internationalization and localization for PyPI,
as well as 2FA and WebAuthn support.

We expect this partnership to tangibly improve the experience for all PyPI users,
from consumers downloading packages,
to package maintainers,
to large corporate teams.
Some of the outcomes we are working toward over the next year include
increased support for package maintainers including multi-maintainer projects,
improvements to reporting infrastructure for malicious projects,
as well as a reduced response time for malware reports and account recovery requests.

<a href="https://jobs.pyfound.org/apply/CKEONredws/PyPI-Safety-Security-Engineer">The job posting can be found here,
and applications for the role are open until June 1st.
Similar to existing developer-in-residence roles,
the contract for this role will be for a one year period,
and the PSF will be actively engaging with our sponsors and supporters
to renew funding for the role in subsequent years.

Ee Durbin is the Director of Infrastructure at
the Python Software Foundation.
They have been contributing to keeping PyPI online, available, and
secure since 2013.

http://<IP_ADDRESS>:8000/posts/2023-05-09-announcing-pypi-safety-and-security-engr-role/
Tue, 09 May 2023 00:00:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-05-09-announcing-pypi-safety-and-security-engr-role/</guid>

</item>

<item>
  <title>Introducing PyPI Organizations</title>

  <author>Ee Durbin</author>

  <category>organizations</category>

  <category>sustainability</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#organizations" class="blogging-tag"><code>#organizations</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#sustainability" class="blogging-tag"><code>#sustainability</code></a>

</div>

Today, we are rolling out the first step in our plan to build financial
support and long-term sustainability of the Python Packaging Index (PyPI),
while simultaneously giving our users one of our most requested features:
organization accounts.

Introducing Organizations

Organizations on PyPI are self-managed teams, with their own exclusive branded
web addresses. Our goal is to make PyPI easier to use for large community
projects, organizations, or companies who manage multiple sub-teams and multiple
packages. We’re making organizations available to community projects for free,
forever, and to corporate projects for a small fee. Additional priority support
agreements will be available to all paid subscribers, and all revenue will go
right back into PyPI to continue building better support and infrastructure
for all our users.

Increasing sustainability and support

In the last year PyPI served 235.7 billion downloads for the 448,941 projects hosted
there. This means that since the previous period, PyPI saw a 57% annual growth in download counts
and bandwidth alike. Having more people using and contributing to Python every
year is an fantastic problem to have, but it is one we must increase
organizational capacity to accommodate.

Increased revenue for PyPI allows it to become a
staffed platform that can respond to support requests and attend to issues
in a timeframe that is significantly faster than what our excellent (but thinly
spread) largely volunteer team could reasonably handle.

Organizations are opt-in

We want to be very clear—these new features are completely optional. If
features for larger projects don't sound like something that would be useful to
you as a PyPI maintainer, then there is no obligation to create an organization
and absolutely nothing about your PyPI experience will change for you.

A basis for future features

We look forward to discussing what other features PyPI users would like to see
tackled next. We know there are lots of ideas out there around safety,
security and usability and we’re looking forward to hearing about anything that
you think would benefit the community. And in the spirit of open source, <a href="https://github.com/pypi/warehouse/issues">we
welcome your feedback on what's on
offer so far.

Get started today

Both community projects (non-profits, NGO’s, hobbyists, etc) and corporate
teams can <a href="https://pypi.org/manage/organizations/">sign up to request their organization name starting
today. Submissions will begin
seeing review and approval in the coming weeks, and corporate teams will be
able to finalize their signup with billing details in May.

Acknowledgements

Organization feature development was approved by the
<a href="https://wiki.python.org/psf/PackagingWG">Packaging Working Group
and funded through the
<a href="https://www.python.org/psf-landing/">Python Software Foundation's
sponsorship program -- thanks to our <a href="https://pypi.org/sponsors/">sponsors</a>
for making this work possible.

We especially want to thank
<a href="https://www.bloomberg.com/company/values/tech-at-bloomberg/?ea-publisher=psf">Bloomberg</a>
for funding our Packaging Project Manager, Shamika Mohanan.

We are also grateful for the many generous PyPI users who shared their
perspectives with Shamika, which laid the foundation for these new features.

And thanks as well to our beta
testers, including the following ✨new✨ PyPI organizations:

Python Cryptographic Authority (<a href="https://pypi.org/org/pyca/">https://pypi.org/org/pyca/</a>)

The Pallets Project (<a href="https://pypi.org/org/pallets/">https://pypi.org/org/pallets/</a>)

certifi (<a href="https://pypi.org/org/certifi">https://pypi.org/org/certifi</a>)

Ee Durbin is the Director of Infrastructure at
the Python Software Foundation.
They have been contributing to keeping PyPI online, available, and
secure since 2013.

http://<IP_ADDRESS>:8000/posts/2023-04-23-introducing-pypi-organizations/
Sun, 23 Apr 2023 00:00:00 +0000
The Python Package Index
  <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-04-23-introducing-pypi-organizations/</guid>

</item>

<item>
  <title>Introducing 'Trusted Publishers'</title>

  <author>Dustin Ingram</author>

  <category>oidc</category>

  <category>publishing</category>

  <category>security</category>

  <description><div class="blogging-tags-grid">

    <a href="http://<IP_ADDRESS>:8000/tags#publishing" class="blogging-tag"><code>#publishing</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#security" class="blogging-tag"><code>#security</code></a>

    <a href="http://<IP_ADDRESS>:8000/tags#oidc" class="blogging-tag"><code>#oidc</code></a>

</div>

Starting today, PyPI package maintainers can adopt a new, more secure
publishing method that does not require long-lived passwords or API tokens to
be shared with external systems.

About trusted publishing

"Trusted publishing" is our term for using the <a href="https://openid.net/connect/">OpenID Connect (OIDC) standard
to exchange short-lived identity tokens between a trusted third-party service
and PyPI. This method can be used in automated environments and eliminates the
need to use username/password combinations or manually generated API tokens to
authenticate with PyPI when publishing.

Instead, PyPI maintainers can configure PyPI to trust an identity provided by a
given OpenID Connect Identity Provider (IdP). This allows allows PyPI to verify
and delegate trust to that identity, which is then authorized to request
short-lived, tightly-scoped API tokens from PyPI. These API tokens never need
to be stored or shared, rotate automatically by expiring quickly, and provide a
verifiable link between a published package and its source.

Using trusted publishing with GitHub Actions

PyPI currently supports trusted publishing with GitHub Actions, using <a href="https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect">their
support for OpenID Connect.

After configuring PyPI to trust a given GitHub repository and workflow, users
of the PyPA's <a href="https://github.com/marketplace/actions/pypi-publish">'pypi-publish' GitHub Action can adopt trusted publishing by
removing the username and password fields from their workflow
configuration, and adding permissions to generate an identity token:

```diff
jobs:
pypi-publish:
name: upload release to PyPI
runs-on: ubuntu-latest

permissions:

 # IMPORTANT: this permission is mandatory for trusted publishing

 id-token: write

steps:
# retrieve your distributions here

   - name: Publish package distributions to PyPI
uses: pypa/gh-action-pypi-publish@release/v1

with:

username: token

password: ${{ secrets.PYPI_TOKEN }}

</ul>
<p>Using the PyPA's GitHub action is strongly recommended, but not required. More
details on how to manually exchange tokens are available <a href="https://docs.pypi.org/trusted-publishers/using-a-publisher/#the-manual-way">in our
documentation</a>.</p>
<h3>Additional security hardening is available</h3>
<p>PyPI package maintainers can further increase the security of their release
workflows by configuring trusted publishers to only release from a specific
<a href="https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment">GitHub Actions environment</a>.</p>
<p>Configuring an environment is optional, but strongly recommended: with a GitHub
environment, you can apply additional restrictions to your trusted GitHub
Actions workflow, such as requiring manual approval on each run by a trusted
subset of repository maintainers.</p>
<h3>Unblocking future security improvements</h3>
<p>In addition to making publishing more secure now, the availability of trusted
publishers unblocks additional future security improvements for PyPI.</p>
<p>Configuring and using a trusted publisher provides a 'strong link' between a
project and its source repository, which can allow PyPI to verify related
metadata, like the URL of a source repository for a project[^1]. Additionally,
publishing with a trusted publisher allows PyPI to correlate more information
about where a given file was published from in a verifiable way.</p>
<p>Finally, although trusted publishers is currently limited to GitHub Actions,
much of the underlying work that went into making this feature possible is
generalizable and not specific to a single publisher. We're interested in
supporting the ability to publish from additional services that provide OpenID
Connect identities.</p>
<h3>Get started today</h3>
<p>To get started with using trusted publishers on PyPI, see our documentation
here: <a href="https://docs.pypi.org/trusted-publishers/">https://docs.pypi.org/trusted-publishers/</a>.</p>
<h3>Acknowledgements</h3>
<p>Funding for this work was provided by the Google Open Source Security Team, and
much of the development work was performed by <a href="https://www.trailofbits.com/">Trail of Bits</a>, with special
thanks to contributor <a href="https://github.com/woodruffw">William Woodruff</a>.</p>
<p>Many thanks as well to <a href="https://github.com/webknjaz">Sviatoslav Sydorenko</a>, maintainer of the PyPA's
<a href="https://github.com/marketplace/actions/pypi-publish">'pypi-publish' GitHub Action</a> for his quick and timely work to add support for
trusted publishers in the action.</p>
<p>Finally, we want to thank all our beta testers, including GitHub staff, for
working with us to ensure this feature is intuitive and useful, and for
providing valuable feedback to improve this feature along the way.</p>
<hr>
<p><em>Dustin Ingram is a maintainer of the Python Package Index and a director of
the Python Software Foundation.</em></p>
<p>[^1]: Currently, information such as this are provided by the uploader and are not verified as accurate by PyPI.</p></description>
      <link>http://<IP_ADDRESS>:8000/posts/2023-04-20-introducing-trusted-publishers/</link>
      <pubDate>Thu, 20 Apr 2023 00:00:00 +0000</pubDate>
      <source url="http://<IP_ADDRESS>:8000/feed_rss_created.xml">The Python Package Index</source>

      <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-04-20-introducing-trusted-publishers/</guid>

    </item>

    <item>
      <title>Welcome to the PyPI Blog</title>

      <author>Ee Durbin</author>

      <category>blogs-about-blogs</category>

      <category>meta</category>

      <category>welcome</category>

      <description><div class="blogging-tags-grid">

        <a href="http://<IP_ADDRESS>:8000/tags#meta" class="blogging-tag"><code>#meta</code></a>

        <a href="http://<IP_ADDRESS>:8000/tags#welcome" class="blogging-tag"><code>#welcome</code></a>

        <a href="http://<IP_ADDRESS>:8000/tags#blogs-about-blogs" class="blogging-tag"><code>#blogs-about-blogs</code></a>

    </div>

<style>
    .md-typeset .blogging-tags-grid {
        display: flex;
        flex-direction: row;
        flex-wrap: wrap;
        gap: 8px;
        margin-top: 5px;
    }

    .md-typeset .blogging-tag {
        color: var(--md-typeset-color);
        background-color: var(--md-typeset-code-color);
    }

    .md-typeset .blogging-tag code {
        border-radius: 5px;
    }
</style>
<p>Today, we're excited to launch <a href="https://blog.pypi.org">blog.pypi.org</a>,
the official blog of the Python Package Index.</p>
<p>One of the most common refrains I hear from Python community members,
irrespective of if they have been around for days or years,
is <em>"I didn't realize that PyPI..."</em>. Followed by something along the lines of:</p>
<ul>
<li>Could <strong>do</strong> that</li>
<li>Is operated with <strong>so</strong> few resources[^1]</li>
<li>Only had <strong>3</strong> administrators[^2]</li>
<li>Needs <strong>more</strong> help</li>
</ul>
<p>That is certainly in part due to the fact that the people[^3] who
make PyPI "happen" are <em>humble</em>, and do so with the limited time they
have to commit to the project among their other responsibilities.
But its also because writing is hard. Harder still when there is
not a convenient tool at hand.
We're hoping that a modern and extensible stack[^4] for this blog
will make writing about and sharing our work more frictionless.</p>
<p>The PyPI team will use this space to communicate with PyPI users,
provide announcements about new features and updates,
interesting technology, as well as share information and
context around PyPI and related efforts of the
<a href="https://www.python.org/psf-landing/">Python Software Foundation</a>.</p>
<p>Stay tuned for more, we're very glad you're here! 💜</p>
<hr>
<p><em>Ee Durbin is the Director of Infrastructure at
the Python Software Foundation.
They have been contributing to keeping PyPI online, available, and
secure since 2013.</em></p>
<p>[^1]: We're thrifty and picky about what we run, but
<a href="https://www.fastly.com/fast-forward">Fastly</a> is the single most
important factor allowing us to get by with comparatively few
resources for our backends.
[^2]: That was until we welcomed Mike Fiedler as an admin in 2023.
[^3]: The PyPI Administrator team is
<a href="https://github.com/dstufft">Donald Stufft</a>,
<a href="https://github.com/di">Dustin Ingram</a>,
<a href="https://github.com/miketheman">Mike Fiedler</a>,
and <a href="https://github.com/ewdurbin">Ee Durbin</a>.
The PyPI Moderator team is
<a href="https://github.com/yeraydiazdiaz">Yeray Díaz</a>,
<a href="https://github.com/cmaureir">Cristián Maureira-Fredes</a>,
<a href="https://github.com/ewjoachim">Joachim Jablon</a>,
<a href="https://github.com/jamadden">Jason Madden</a>,
<a href="https://github.com/pradyunsg">Pradyun Gedam</a>,
and <a href="https://github.com/theacodes">Stargirl Flowers</a>.
[^4]: Shout-out: This blog is hosted on
<a href="https://readthedocs.org/">Read the Docs</a>,
using the <a href="https://pypi.org/project/mkdocs/">MkDocs</a>
static site generator,
and the <a href="https://pypi.org/project/mkdocs-material/">Material for MkDocs</a> theme.
Many thanks to the maintainers of those projects for your
contributions,
we're very excited to have our blog contents live side-by-side
with our other documentation and code in
<a href="https://github.com/pypi/warehouse">pypi/warehouse</a>!</p></description>
      <link>http://<IP_ADDRESS>:8000/posts/2023-03-21-welcome-to-the-pypi-blog/</link>
      <pubDate>Tue, 21 Mar 2023 00:00:00 +0000</pubDate>
      <source url="http://<IP_ADDRESS>:8000/feed_rss_created.xml">The Python Package Index</source>

      <guid isPermaLink="true">http://<IP_ADDRESS>:8000/posts/2023-03-21-welcome-to-the-pypi-blog/</guid>

    </item>

  </channel>
</rss>

ref: #13813

Every previewer I could find at hand, renders the result pretty terribly.
I think this needs more investigation and someone to commit to figuring out how to render sanely in readers.


Fix typo in swedish translation

The Swedish word for "Forbidden" is "Otillåtet", not "Ottillåtet".
(I have attempted to join the Swedish translation team on transifex, and will check more of the translation if/when accepted there, but this one is a simple typo, so I thought I might as well try to submit it as this too.)

Thanks for the report, however, translations are handled at Transifex.

Yes.  Unfortunately, there seem to be no way of notifying the translation team about a typo, and my request to actually join the Swedish translation team on transifex (feels like overkill for a small typo, but anyway) hasn't got any response yet.


Update to run with ODB 2.1.6 and some smaller changes

This has a number of changes, so the ODB studio also works properly.
Scott

This looks good. Lets see what @chrismichaels84 has to say

Ok. I've also cleaned it up. I hope it is mergeable. :smile:
Scott

@smolinari This looks good to me, but I can't test it right now. My internet isn't so great atm. I'll have a pull and run vagrant tomorrow just to be sure.
@PommeVerte, it would be nice if vagrant and Travis shared some bootstrapping. That  way we only have to change versions in one spot. I tried (for a few minutes) but had troubles with working directories. Any thoughts? Is this even worth the effort?

Yeah I think it's worth the effort. I didn't have a proper look at the vagrant build but I think a few things can be done.

This looks great. Merging.


VSCode 1.63.2 Install Plugins

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.63.2
OS Version: Windows Server Standard 2019 Version	10.0.17763 Build 17763

Steps to Reproduce:

Start VSCode
Install PlugIns
in Shared Process i got the Error "DevTools failed to load source map: Could not load content for https://ticino.blob.core.windows.net/sourcemaps/899d46d82c4c95423fb7e10e68eba52050e30ba3/node_modules/applicationinsights/out/Library/EnvelopeFactory.js.map: Certificate error: net::ERR_CERT_AUTHORITY_INVALID"

Regards
Thomas

Do you mind providing information about what extensions you installed? I have plenty of extensions installed and don't see this


Migrated Batch3 of Thermal Conductivity

[ ]  Formula should be updated too.
[ ]  CI should be green

Formula is already updated and second line
I didn't understand it  ?

[ ]   Formula should be updated too.
[ ]   CI should be green

Formula is already updated and second line
I didn't understand it ?

Formula doesn't seem updated:

CI (continuous integration tests are failing). They should PASS before you withdraw the attention of any reviewer.

@qur786 Read the reviewers' comments thoroughly. It was clearly mentioned not to request reviews until CI is passing.
I apologise for that sir .
I didn't actually see that comment.
And sir what to do when , CI test fails?


Support of OWS metadata in process definition

In the current pywps-4 implementation one can provide metadata (for process, inputs and outputs) only as a list of strings. These strings become then OWS metadata elements with a title attribute.
The OWS metadata element has also the href attribute. I extensively use the metadata to provide links to external docs to enhance the process documentation (users need to understand what the process does :)
I provide a patch where one can provide a list of tuples [(title, href), ] for metadata in addtion to a list of strings. But i don't know how you would like to have it ...

cc @jachym @ldesousa
@cehbrecht thanks for the report and associated PR in #190.
IMHO it's a good time to change the Process model to make metadata a list of dicts, i.e.:
...
metadata=[
    {
        'title': 'foo process',
        'href': 'http://example.org/foo,
    },
    {
        'title': 'foo process more documentation',
        'href': 'http://example.org/bar'
    }
]
...

..thus following the OWS metadata model from OWS 1.1.0.
Thoughts?

Sample diff:
diff --git a/pywps/app/Process.py b/pywps/app/Process.py
index e52e746..bfc2ea5 100644
--- a/pywps/app/Process.py
+++ b/pywps/app/Process.py
@@ -112,7 +112,14 @@ class Process(object):
             doc.append(OWS.Abstract(self.abstract))

         for m in self.metadata:
-            doc.append(OWS.Metadata({'{http://www.w3.org/1999/xlink}title': m}))
+            metadata = {}
+            if 'href' in m:
+                metadata['{http://www.w3.org/1999/xlink}href'] = m['href']
+            if 'title' in m:
+                metadata['{http://www.w3.org/1999/xlink}title'] = m['title']
+            if 'type' in m:
+                metadata['{http://www.w3.org/1999/xlink}type'] = m['type']
+            doc.append(OWS.Metadata(metadata))

         for p in self.profile:
             doc.append(WPS.Profile(p))

According to the specification there can indeed be more than one metadata reference element. But it is defined in another document, I guess that is why no one ever complained about it.
I would prefer to have a Metadata class instead of a list of assorted composition. Does it exist in OWSLib?
Also, the '{http://www.w3.org/1999/xlink}' string should be promoted to a property to avoid replication.

@ldesousa there is no Metadata class in OWSLib (note OWSLib is mainly for parsing, not serializing).  having pywps.app.Process.metadata as a class would require a bit more from users when setting up their processes as opposed to passing a simple dict, but we already expect that given pywps.app.Process.inputs.
Having said this, how about a Metadata class in pywps.app.Process?  So then:
from pywps.app.Process import Metadata
...
metadata=[Metadata('foo process', 'http://example.org/foo'), Metadata('foo process more documentation', 'http://example.org/bar')]

Yes, it was something like that I had in mind. You know, Computer Scientists formalities, but that long run facilitate things.

+1 for this kind of Metadata class.

cc @jachym
FYI associated pull request in #195 for review/comment/merge.

Big thanks works for me

Implemented in #195.


fix: simplify rewrite rule

:tada: This PR is included in version 2.9.2-stage.1 :tada:
The release is available on:

npm package (@stage dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 2.9.2 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


getInjectedObject override

[x] I have searched the issues of this repository and believe that this is not a duplicate.
[x] I have checked the FAQ of this repository and believe that this is not a duplicate.

Environment

Dubbo version: 2.7.3
Operating System version: ubuntu 18.04
Java version: 1.8

Steps to reproduce this issue
it's a suggestion, the method "org.apache.dubbo.config.spring.beans.factory.annotation.AnnotationInjectedBeanPostProcessor#getInjectedObject" is a protected method, but attr "injectedObjectsCache" is private. so when i override the method, it's very difficult, there are lots of modifitions. so can the attr be protected?

AnnotationInjectedBeanPostProcessor has been removed from Dubbo's source code repo and now exists as a third part dependency in spring-context-support.
If u really have that need, please submit a PR there.


Document how to render different content based on roles from templates

I propose that the instructions on https://hexdocs.pm/pow/user_roles.html would include how to render templates conditionally based on user roles. e.g. admin.

Added in #457 thanks 😄


Create snapshot test for adminTable components

Checklist:

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)

Tackling #309

@Code-Victor Per our conversation, here are steps for your consideration:

"This branch is out-of-date with the base branch" — which you resolved during our meeting
You can @ Utsab, such as @utsab, to re-reviewing your pull request
Creating a commit with multiple authors at https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
GitHub workflow: Try if multiple team members should work in the same or separate repositories; it depends.

@Code-Victor There are missing space characters in:
Co-authored-by: Alade<EMAIL_ADDRESS>Co-authored-by: Ayomide<EMAIL_ADDRESS>
You need to add a space character   before the < character.

@Code-Victor lgtm; the new commit says "3 people committed":

Please contact @GuillermoFloresV if you have further questions about this. Thanks!


Errors reported in the wrong location

First of all, here's a reproduction case: https://github.com/LPGhatguy/gulp-sass-sourcemaps-bug
I'm having strange issues with a combination of variable interpolation and multi-line selectors causing gulp-sass to report errors in the wrong spots. In the above example, the error is off by one line, but in one of my test projects that started my hunt for the bug, I have errors that are off by over 100 lines!
In addition, the file is reported as being stdin, which although fixed in sourcemap generation, does not work in error output in this case.

This issue appears to be still relevant with the latest versions of each dependency. Has anyone reviewed this issue yet?

Remove all other gulp plugins. If the issue persists please open an issue with libsass (used by gulp-sass).


[Draft] CI: Rework toolchain setup

This avoids double-installation of rust-toolchains in CI and enables coloring in the output.
Fixes https://github.com/hermitcore/libhermit-rs/issues/226.

This is now ready for review. Windows CI is failing everywhere currently, because the NASM servers are down.
This started as a fix for #226, but it grew to a whole rework of the GitHub Actions workflows.
The idea regarding #266 is that rustup and cargo automatically set up the toolchain according to rust-toolchain.toml, so I introduced a step calling rustup show, which does exactly this.
I also added the CARGO_TERM_COLOR: always environment variable, to have nicely colored output even in CI.
We can omit the -Z build-std=core,alloc,panic_abort -Z build-std-features=compiler-builtins-mem --target x86_64-unknown-hermit-kernel.json, since these settings are automatically picked up by cargo nowadays.
It was also possible to streamline the test workflow, reducing the differences between the operating systems.
Note that this includes https://github.com/hermitcore/rusty-loader/pull/24 via a sed invocation.

bors try


fix(masthead): prevent extra space beneath megapanel columns in Safari

Related Ticket(s)
none
Description
Fixes an issue that only presents on Safari where megamenu tabpanels are unnecessarily tall.
Before:

After:

Changelog
Changed

Prevents masthead megamenu tabpanels from displaying with excessive vertical space in Safari.

While working on this I realized that something has gone wrong with the focusout handling for megamenus in Safari 💀 The event.relatedTarget is always null, whereas we expect it to be the element that is losing focus. Will open a separate ticket for that.


Fix Errors in Swift 2 / Xcode 7

The pod is unable to compile in Xcode 7.
This commit fixes the issues introduced in Xcode 7 / Swift 2.0.

pig @mikaoj

Great! Made some comments, let me know if you want to fix them...or I'll just do it myself :)

I've fixed the straight-forward ones, @mikaoj. Would you mind having a look at the unwrapping?
Thanks for the library!


Fix grafana workload dashboard mismatched quantiles query

Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[x] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[x] Does not have any changes that may affect Istio users.

Hi @AEGQ. Thanks for your PR.
I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@AEGQ could you please run  ./manifests/addons/gen.sh from the istio/istio root dir to update the grafana.yaml file as well.

/ok-to-test

@AEGQ: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
fc813bc08f9a4854331f5693670dabef76f536e3
link
/test release-notes_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@AEGQ: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

release-notes_istio
fc813bc08f9a4854331f5693670dabef76f536e3
link
/test release-notes_istio

integ-multicluster-k8s-tests_istio
fc813bc08f9a4854331f5693670dabef76f536e3
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@carolynhu I have submitted an update to grafana.yaml and no other problems have been found so far.
But I encountered an error when executing ./manifests/addons/gen.sh, and fixed by change client to true.

https://github.com/istio/istio/blob/e2da6e166f44541c1a0316c587e151db61b67191/manifests/addons/gen.sh#L71
https://github.com/istio/istio/blob/e2da6e166f44541c1a0316c587e151db61b67191/manifests/addons/gen.sh#L77

@AEGQ
--dry-run support for kubectl 1.15 only have bool option
ref: https://v1-15.docs.kubernetes.io/docs/reference/kubectl/overview/#

@AEGQ: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

integ-multicluster-k8s-tests_istio
23223afd10f8ad77cdcbd71548e6cc44c43eed67
link
/test integ-multicluster-k8s-tests_istio

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/test integ-multicluster-k8s-tests_istio


Failed smargon move on pin tip centre causes detector not to clean up [Timebox: 2 days]

We had a hardware issue where the smargon failed to move https://graylog2.diamond.ac.uk/messages/logs_8656/56894842-ce7f-11ee-8ab3-1866dafae904. This left the eiger in a bad state as the next collection (https://ispyb.diamond.ac.uk/dc/visit/cm37235-1/dcg/11281776) failed to arm.
Note: If we don't make any progress in the 2 days then we should instead propose converting the eiger to ophyd-async next sprint
Acceptance Criteria

When the pin tip centre fails like this the next collection is able to run smoothly

Tried to reproduce by putting:
    global TEST_FAIL
    if TEST_FAIL:
        TEST_FAIL = False
        raise Exception()
``` in `move_smargon_warn_on_out_of_range` but couldn't. I think this might only occur when the exception gets raised at a specific time during the arming procedure?

We need to test calling eiger.stop() at various points in the arming chain and confirm it tidies up. Also, with more logging we might be able to find out where in the chain we were when we got the error.

This looks to fail at the same point as #1169 with the same message
XXX - [2024-02-18 17:29:07,159] ophyd status ERROR: SubscriptionStatus(device=eiger_odin_meta_ready, done=True, success=False) encountered an error during _handle_failure()
Traceback (most recent call last):
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 260, in _run_callbacks
    self._handle_failure()
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 760, in _handle_failure
    return super()._handle_failure()
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 654, in _handle_failure
    self.device.stop()
AttributeError: 'EpicsSignalRO' object has no attribute 'stop'

This looks to fail at the same point as #1169 with the same message
XXX - [2024-02-18 17:29:07,159] ophyd status ERROR: SubscriptionStatus(device=eiger_odin_meta_ready, done=True, success=False) encountered an error during _handle_failure()
Traceback (most recent call last):
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 260, in _run_callbacks
    self._handle_failure()
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 760, in _handle_failure
    return super()._handle_failure()
  File "/dls_sw/i03/software/bluesky/hyperion_v8.9.0/hyperion/.venv/lib/python3.10/site-packages/ophyd/status.py", line 654, in _handle_failure
    self.device.stop()
AttributeError: 'EpicsSignalRO' object has no attribute 'stop'

I believe this is after the initial failure as it's trying to clean up. See https://github.com/DiamondLightSource/dodal/issues/294


Explore RestBird for testing

Explore whether RestBird could be a useful addition to our testing pipeline.

Tool is abandoned.  No commits since Nov 29, 2018.


Minor update FunctionalTests-Power.xml to remove HyperV support

Notice that adding the Hyper-V support in the commit https://github.com/LIS/LISAv2/commit/7e1e2402be99e7ae5704d28175966ebe9e876b66#diff-dcbe3953e67d7d52d7877c20ef074614 , and this Power Hibernation is new feature in the upstream kernel, it is so great that LISAv2 has auto case about this feature.
Looks that Power-Hibernate.ps1 does not support Hyper-V yet, vm operations are AZVM related. So suggest to remove Hyper-V support in case xml until updating Power-Hibernate.ps1 to support Hyper-V or add new case for Hyper-V later.   Thank you.
Test Result in Hyper-V with RHEL 8 VM：
03/05/2020 02:36:43 : [INFO ] Test script: Power-Hibernate.ps1 started.
03/05/2020 02:36:43 : [INFO ] C:\Users\xuli\LISAv2\Testscripts\Windows\Power-Hibernate.ps1 -TestParams ;hb_branch=next-20200210;hb_url=git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -AllVmData @{HyperVHost=xxx; HyperVGroupName=LISAv2-OneVMhb-20190225-EM84-637190012970; PublicIP=xxx; InternalIP=xxx; RoleName=LISAv2-OneVMhb-20190225-EM84-637190012970-role-0; VMGeneration=2; SSHPort=22} -TestProvider HyperVProvider -CurrentTestData System.Xml.XmlElement
03/05/2020 02:36:43 : [DEBUG] Prepare swap space for VM LISAv2-OneVMhb-20190225-EM84-637190012970-role-0 in RG .
03/05/2020 02:36:43 : [INFO ] Generating constants.sh ...
03/05/2020 02:36:43 : [INFO ] hb_url=git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git added to constants.sh
03/05/2020 02:36:43 : [INFO ] hb_branch=next-20200210 added to constants.sh
03/05/2020 02:36:43 : [INFO ] constants.sh created successfully...
03/05/2020 02:36:44 : [ERROR] EXCEPTION : Cannot bind argument to parameter 'ResourceGroupName' because it is null. at line: 48
03/05/2020 02:36:44 : [INFO ] ==> Upload test results to database.
03/05/2020 02:36:44 : [INFO ] ==> Check if the test target machines are still running.
03/05/2020 02:36:44 : [INFO ] Trying to connect to deployed VMs.
ID TestArea             TestCaseName                                                                TestResult TestDuration(in minutes)
1 POWER                Power-hibernate                                                                   FAIL                 0.81

@dcui I forgot to test in hyper-v. Have you tested in your Hyper-v?

@dcui I forgot to test in hyper-v. Have you tested in your Hyper-v?

Yes, I tested the hibernation feature on my local Hyper-V hosts (2019, 2016, 2012 R2) and basically it worked fine with the issues we already knew about on Azure.

I am working on this issue still. @lubaihua33 setup may have the different reason to fail the test. It did not get the IP address of new VM. I will find if they are related.


Error setting working directory

After setting work dir in JobExecutorConfig:
config = psij.JobExecutorConfig(launcher_log_file="/data/launcher.log" , work_directory="/data/.psij/")
jex = psij.JobExecutor.get_instance('slurm', config=config)

the following error occurs:
  File "/usr/local/lib/python3.9/site-packages/psij/executors/batch/batch_scheduler_executor.py", line 187, in __init__
    self.work_directory = config.work_directory / self.name
TypeError: unsupported operand type(s) for /: 'str' and 'str'

See https://exaworks.org/psi-j-python/#docs/.generated/psij.html/#module-psij.job_executor_config
The work_directory parameter must be a pathlib.Path.

A check or auto conversion would be nice.


Update theme/colors to Material 3.

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).
Fixes #1424
Description
Existing catalog app codebase referring material 2 color theme.
It is required to update color theme as per material 3.
Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
Type
Choose one: Feature
Screenshots (if applicable)
Checklist

[x] I have read and acknowledged the Code of conduct.
[x] I have read the Contributing page.
[x] I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA.
[x] I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach.
[x] I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project.
[x] I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally.
[x] I have built and run the demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

Basically, this pr will unblock other ui issues which are related to material 3 color theme, those ui fixes will be provided on top of it. As this pr has all material 3 brand colors.


Bug report: NS_ERROR_FILE_NO_DEVICE_SPACE

This happens when just visiting the homepage.
Browser: Firefox Quantum 59.0.2
OS: Arch Linux
NS_ERROR_FILE_NO_DEVICE_SPACE:
Filename: https://gchq.github.io/CyberChef/main.js
Line: 135
Error: [Exception... "File error: No device space"  nsresult: "0x80520010 (NS_ERROR_FILE_NO_DEVICE_SPACE)"  location: "JS frame :: https://gchq.github.io/CyberChef/main.js :: d.prototype.loadLocalStorage :: line 135"  data: no]
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
CyberChef version: 7.10.0

So apparently I didn't have a single byte left on my drive. After removing some files, the error disappeared. Sorry for bugging you :sweat_smile:


Elastic APM  is oss

Elastic APM server and agent are oss https://github.com/elastic/apm-server/
storage and ui elasticsearch and kibana are oss.

@AlexanderWert I think this is correct but can you verify that this is the case for sure? Thanks

apologies for the delay @shalk, merging this now based on your pointers that it is OSS for sure. if this is not correct, someone can provide a PR to revert this change


bundle extension scripts

Re #197
We didn't bundle any extension code or node modules and since we don't have any module lazy loading, the extension activation is really slow.
Here is the activation time comparison between unbundled and bundled version
Original

Bundled

The activation time decreases by around 80%. Moreover, the extension vsix size before bundling is 7.6MB while the bundled one is 3MB, which is almost half of the original size.

I ran into a couple of issues when trying to debug the extension. After checking this out I ran npm install and then the build task, and tried to debug. The break points I set didn't seem to actually get loaded, and the overview page also didn't load while debugging.  Is there anything I missed in the setup?

@RMacfarlane I pushed a change to ensure that debugging works on both Windows and macOS.


Fix ValidationError export

'types/ValidationError' ends up being resolved incorrectly when consuming this package from npm, with moduleResolution: 'node' configured in the TypeScript compiler.
You could alternatively switch it to './types/ValidationError' (with the leading ./ making the path relative) but since ValidationError is already imported from that path earlier in the file, it doesn't seem necessary?

Hi, thanks for the fix! Looks good

Released in https://github.com/apideck-libraries/better-ajv-errors/releases/tag/v0.2.4


What is the license?

Hi
I don't find any information regarding the license under which this amazing script is published. May you add a good Free Software license for the project?

Hi
Sorry for the delay. I already added the MIT license to the project.


Discuss: Assets only support Object (should support string shorthand)

Corollary to https://github.com/angular/angular-cli/issues/10267

So for this to happen we'd have to look at
assets: [
  "src/favicon.ico",
  "src/assets",
]

and know that it should be converted to
assets: [
  {
    "glob": "src/favicon.ico",
    "input": "src/",
    "output": "/"
  },
  {
    "glob": "**/*",
    "input": "src/assets",
    "output": "/assets"
  }
]

There's two parts to this:

differentiating between directories (glob is **/*) and files (glob is the file itself)
determining output paths

It's fairly straightforward to determine the glob by checking the if the string is for a dir or for a file.
But it's not easy at all to determine the output path. We usually put stuff in src/, and expect src/ to 'translate' to the output root. But this concept is not explicit or configurable.
In other words: just by looking at "src/assets" we cannot know that the output path should be /assets because we don't know that src/ is conceptual output root.

We addressed this issue by adding a sourceRoot property to projects that is meant to represent the root of the source files, assets and index.html file structure.


belindas-closet-nextjs-contact-page

This user story has no testing with routes. It look okay a little for now.

This looks good, although we might want to consider the naming for the directory to be all lowercase letters as the routes appear to be case-sensitive, meaning routing to /contact-page is not the same as routing to /Contact-Page. This would also keep with the "lowercase-words-separated-by-dashes" convention. Just a thought.

Hi @cshimm, Thank you for your advise!. I will fix that and update again!

Good afternoon. @kaimanasse15 . I'm going to ask you make some revisions before approving this request. I know, these projects are a lot to jump into all of a sudden. Hopefully, my requests are understandable and can help you get more comfortable working on this project. And feel free to ask me any clarifying questions :)

If this is just an update to the changes you made on your other pull request, can you delete your older pull request?

can you reformat the name of this pull request? If you look at the other pull requests currently open, you can see our usual  naming convention. You don't need the angular brackets.
You can also look at older pull requests by clicking here on the pull request page

can you request reviews from others when you submit a pull request? You can do this on the right side of this page by clicking the little gear next to "Reviewers". You can select a few people you'd like to review this PR and I'd suggest you include SeattleColleges/Leadership in those selections. That will tag all the members of the leadership team without you having to select each of them one by one.

can you add a link to the contact page to the navbar? you can do this in the components/ Navbar.tsx file.  You just have to add the name of the page and the URL address to these two arrays.

As I said, this is a lot to jump into. Hopefully this all helps you get into the flow of things!

This is a good start but the code only provides a basic structure for the contact page. As requested I think you should change to naming to lower case letters to match the naming of the rest of the directories. Other thank that I think you are off to a great start.

@tinpham5614, will you have some time to hope on to see my route? The place holder is error. Nick didn''t find any problem with my route. Thank you

This is the contact page that I am seeing on my end:

Looks okay and barebones, definitely needs routing as mentioned by others, but good start

@Asfand00 if you're still awake, can you try fetching this branch to your machine and testing to make sure the Contact button in the nav bar links to the placeholder contact page and approve this pull request if it does?

I don't think I have authority to approve this PR @nickolasram but I tested the page again, this is the result:

I can personally approve that this page works as it is

@Asfand00 try going to the "Files Changed" tab and see if you can click on the green "Review Changes" button

@taylorpapke can this PR be manually merged? Everything works but Kai's commits weren't signed.

@kaimanasse15 Please reach out to @tinpham5614 or @bcko to troubleshoot signing commits. You also have to remember to sign the commits after you've created your key. It may be helpful to look into auto-signing your commits (which is what I do).
Here is a good bit of advice from GitHub's docs:
To configure your Git client to sign commits by default for a local repository, in Git versions 2.0.0 and above, run git config commit.gpgsign true. To sign all commits by default in any local repository on your computer, run git config --global commit.gpgsign true.
To store your GPG key passphrase so you don't have to enter it every time you sign a commit, we recommend using the following tools:
For Mac users, the GPG Suite allows you to store your GPG key passphrase in the macOS Keychain.
For Windows users, the Gpg4win integrates with other Windows tools.
You can also manually configure gpg-agent to save your GPG key passphrase, but this doesn't integrate with macOS Keychain like ssh-agent and requires more setup.


Change all M_PI  to CGFloat.pi for Swift 3.0

For old versions of Swift, you use M_PI to refer to the pi constant. Swift 3 integrates the pi constant in the Float, Double and CGFloat types:
Float.pi
Double.pi
CGFloat.pi

Thanks 👍


Rocket.Chat from the Mac App Store is multiple versions out of date

My Setup

Operating System: macOS Big Sur 11.3.1
App Version: 3.0.3
Installation type: Mac App Store

[x] I have tested with the latest version
[x] I can simulate the issue easily

Description
Mac App Store offers Rocket.Chat 3.0.3 as the latest version when Rocket.Chat 3.2.2 is the latest version.
Current Behavior
Mac App Store offers Rocket.Chat 3.0.3 as the latest version
Expected Behavior
Mac App Store offers Rocket.Chat 3.2.2 as the latest version

This is still an issue. The app store version is still 3.0.3 when the latest is 3.1.1.

Can we please get some Eyes on this and PUSH the MAC store app to 3.1.1

Let's put it the other way: it's half of the year out of date :godmode:

"Its dead Jim"

I worked around managing to find Mac app from the site. But, otherwise, considering to switch to MatterMost, as RocketChat is too many bugs out of the properly work instrument.

The App Store also shows version 3.0.0 as the latest version but the version shown in Rocket.Chat is 3.0.3. 🤔

As of this comment, the Rocket.Chat app is still stuck at version 3.0.0....

Technically 3.0.3, but the fact that it is left as 3.0.0 really reflects on the failure to update rocket.chat.

The AppStore Version is the only one with the right macOS security entitlements for accessing video and audio (Jitsi integration or audio recording) but still crash in the actually accessible MAS v3.0.3. The v.3.x DMG/pkg distributions (actually v3.5) are missing them, therefore they crash as soon as audio or video is involved: https://github.com/RocketChat/Rocket.Chat.Electron/issues/1912#issuecomment-877281039

Please update! AppStore is still on 3.0.0 and will not receive updates

Apple changed the requirements to be able to update the app on Apple Store.
We will be working on this in the next weeks.

Apple changed the requirements to be able to update the app on Apple Store.
We will be working on this in the next weeks.

Is there anything in specific that prevents the app from being compiled for the App Store?\

I'm investigating yet, but we will need to implement a login with Apple Account if I'm not wrong.
I don't know if they will accept our live update too, maybe we will need to disable it on the Apple Store version too.
But I'm not sure about each requirement yet.
You can install the released DMG from Github that will work right now.

They will definitely ask you to remove the auto update mechanism.

I'm investigating yet, but we will need to implement a login with Apple Account if I'm not wrong. I don't know if they will accept our live update too, maybe we will need to disable it on the Apple Store version too. But I'm not sure about each requirement yet.
You can install the released DMG from Github that will work right now.

Why don't you link that version on the web page? Using the very outdated "official" App Store version really puts a bad light on Rocket.Chat.

The Apple Store version is updated, you can install it from there right now.


Gojo source won't play zaza server

resubmit more proper issue with contents & all informations like versions & device info.


chore(cloud-rad): Add code fencing

Code examples need code fencing around them to distingish from
rich text for TSDoc.
Internally b/179483748
Script used:
https://github.com/fhinkel/cloud-rad-script/blob/main/fixExampleComments.js

For some reason I thought this is the handwritten vertex library.


Clicking link to "Edit" or "Remove" comments makes page jump

The same issue we just fixed w/guidance tabs is also affecting comment links. When I click the "Edit" or "Remove" links on plan Write page the focus jumps to the top of the page.

No longer an issue. Closing out


Sqlite Configuration Options

Hi SRombauts,
It seems helpful to add configuration options in Database's constructor, isn't it?
Please see http://www.sqlite.org/c3ref/c_config_getmalloc.html for details.

Here are some mode to use on different occasions:
SQLITE_CONFIG_SINGLETHREAD
This option sets the threading mode to Single-thread.
SQLITE_CONFIG_MULTITHREAD
This option sets the threading mode to Multi-thread.
SQLITE_CONFIG_SERIALIZED
This option sets the threading mode to Serialized.

Hi, thanks for all your suggestions, I'll take some time to think and answer them.
I  mostly don't want to break existing API since I know released 1.x
Cheers!


Implement an algorithm for simplifying spellings within a temperament

Seem quite specific to temperaments maybe that's a better home for this. Could implement split spelling as well.

Moved to temperaments.


199 show space bytes

Description
the statistics view for spaces now shows bytes per space.
Review Time Estimate

[x] When possible

Types of changes

[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x ] I have updated the CHANGELOG.md.
[ x] I have signed the CLA
[ x] I have updated the documentation accordingly.
[x ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

@max-zilla will fix that and make another commit

@max-zilla I fixed the part on app/controllers.
That should be done, I do need to test and commit the update script.

Also committed the db update for adding space bytes to existing spaces.


Is the backbone Denoising Unet need training？

Is the backbone Denoising Unet need to be finetuned? Or it is frozen as the SD 1.5 model?
In the paper, it says, "During this stage (second), we only train the temporal layer while fixing the weights of
the rest of the network.‘’
But I see your chechpoint containing the Denoising Unet?
So I got confused, please answer this question, thanks！

Denoising Unet is trained in the first stage and freezed in the second stage. Temporal layers are trained base on the stage-1 denoising unet.


⚠ Bofrost.fr has degraded performance

In ec6c847, Bofrost.fr (https://www.bofrost.fr) experienced degraded performance:

HTTP code: 200
Response time: 1986 ms

Resolved: Bofrost.fr performance has improved in 4e8b4ab.


test: proptest Type validation and substitution

Add proptest::Strategys that produce valid/well-formed Types/etc.

CustomTypes being correct wrt. the TypeDef's in the ExtensionRegistry passed in
such that any TypeArgs are correct for the TypeParams into which they must fit (e.g. in those TypeDefs)
containing variables, with the strategy also returning an appropriate "environment" i.e. Vec<TypeParam> declaring all variables that are used
(all this done by a fold or "State monad"-like mechanism of passing in an environment to each Strategy that then returns a copy of that environment with potentially more variables.)

Using std_reg(), thus produce types and valid substitutions for the variables in those types; check the type is valid in the original environment, and after substitution, is valid in the environment for the substituted-in values.
Coverage of making TypeArgs for TypeParam::{List, Tuple, Extensions} is missing because the std_reg() does not declare any types taking those kinds of type arguments (!)....
Plan to extend this to test substitution of nodes/operations, in time, that will probably be a second PR.
Main questions (and draft-ness) here relate to how to organise the code, and what old code we might remove given this.

Here's an example:

original type TypeBase(Extension(CustomType { extension: IdentList("collections.list"), extension_ref: (Weak), id: "List", args: [Type { ty: TypeBase(Variable(0, Any), Any) }], bound: Any }), Any)
original environment [Type { b: Any }]
Substituted variable 0: Type { ty: TypeBase(Sum(General { rows: [TypeRowBase { types: [TypeBase(Function(FuncTypeBase { input: TypeRowBase { types: [TypeBase(Extension(CustomType { extension: IdentList("prelude"), extension_ref: (Weak), id: "usize", args: [], bound: Copyable }), Copyable)] }, output: TypeRowBase { types: [TypeBase(Variable(0, Any), Any)] }, runtime_reqs: ExtensionSet({IdentList("logic")}) }), Copyable), TypeBase(Extension(CustomType { extension: IdentList("prelude"), extension_ref: (Weak), id: "qubit", args: [], bound: Any }), Any), TypeBase(Extension(CustomType { extension: IdentList("arithmetic.float.types"), extension_ref: (Weak), id: "float64", args: [], bound: Copyable }), Copyable)] }] }), Any) }
result: TypeBase(Extension(CustomType { extension: IdentList("collections.list"), extension_ref: (Weak), id: "List", args: [Type { ty: TypeBase(Sum(General { rows: [TypeRowBase { types: [TypeBase(Function(FuncTypeBase { input: TypeRowBase { types: [TypeBase(Extension(CustomType { extension: IdentList("prelude"), extension_ref: (Weak), id: "usize", args: [], bound: Copyable }), Copyable)] }, output: TypeRowBase { types: [TypeBase(Variable(0, Any), Any)] }, runtime_reqs: ExtensionSet({IdentList("logic")}) }), Copyable), TypeBase(Extension(CustomType { extension: IdentList("prelude"), extension_ref: (Weak), id: "qubit", args: [], bound: Any }), Any), TypeBase(Extension(CustomType { extension: IdentList("arithmetic.float.types"), extension_ref: (Weak), id: "float64", args: [], bound: Copyable }), Copyable)] }] }), Any) }], bound: Any }), Any)
Which is to say, List<Var(0)> substituted with variable 0 = some-crazy-sum produces List<some-crazy-sum>, ho hum.


unexpected status code 200 while pushing to pushgateway

hi
I use k8up v0.1.10 and wrestic v.0.2.0.
The backup job throws an error when the backup-job pushes to the prometheus pushgateway:
I0813 23:02:09.739192       1 handler.go:44] wrestic/statsHandler/promStats "level"=0 "msg"="sending prometheus stats"  "url"="https://pushgateway.example.com"
E0813 23:02:09.741696       1 backup.go:145] wrestic "msg"="prometheus send failed" "error"="unexpected status code 200 while pushing to https://pushgateway.example.com/metrics/job/restic_backup/instance/backup: "

In the pushgateway I see that the data was send successfully...
I have defined the pushgateway url in the k8up BACKUP_PROMURL env variable.
Any ideas why this happens?

Hi @gi8lino
Can you reproduce this issue with wrestic 0.1.9? It reports that the code is 200, which indicates that it worked. Maybe there's a bug in the status check.
Are the metrics there after the backup ran?
Best
Simon

Hi @Kidswiss
With wrestic 0.1.9 there is no log entry if something was send to the pushgateway.
Yes, it is a 200, but wrestic reports it as an error. As in the log written, the error occurs in line 145 in backup.go.
I found an issue. Maybe the client_golang is outdated.
I also found another issue to this problem which refers to actual prometheus go code here. Maybe this can help you...
Yes, the metrics are in the pushgateway.

Hi @gi8lino
Thanks for digging into this, I'll have a look at that.
Best
Simon

Hi @gi8lino
Finally had some time to get to this.
A simple update of the prometheus libraries in wrestic solves the issues.
0902 15:26:06.819188   22487 handler.go:44] wrestic/statsHandler/promStats "level"=0 "msg"="sending prometheus stats"  "url"="http://localhost:9091/"
I0902 15:26:06.838591   22487 backup.go:86] wrestic/backup "level"=0 "msg"="backup finished, sending snapshot list"
I0902 15:26:06.838612   22487 snapshots.go:37] wrestic/snapshots "level"=0 "msg"="getting list of snapshots"
I0902 15:26:07.423279   22487 handler.go:68] wrestic/statsHandler/webhookStats "level"=0 "msg"="sending webhooks"  "url"="http://localhost:8091"

Opened https://github.com/vshn/wrestic/pull/23 for this.
Thanks for reporting the issues!
Best
Simon

Hi @Kidswiss
As soon as a new wrestic release is created, I will test it.
Best
gi8

Hi @Kidswiss
Any news about the pr?
Best
gi8

@gi8lino Sorry for the long radio silence.
I can build a temp image for further testing. If some other unforseen issues would arise.

@Kidswiss
A temp image would help and I will test it!

@gi8lino
You can use vshn/wrestic:prom_fix for testing. Looking forward to your results.

@Kidswiss
At the beginning I had some issues with the backups. It didn't find the buckets. I delete all the buckets and then the backups worked properly.
Now also the status code from prometheus seems to be processed correctly:
I0927 23:02:10.242398       1 handler.go:44] wrestic/statsHandler/promStats "level"=0 "msg"="sending prometheus stats"  "url"="http://prometheus-pushgateway.monitoring.svc.cluster.local:9091"
I0927 23:02:10.259513       1 backup.go:86] wrestic/backup "level"=0 "msg"="backup finished, sending snapshot list"
I0927 23:02:10.259549       1 snapshots.go:37] wrestic/snapshots "level"=0 "msg"="getting list of snapshots"


Safe-Management - using CSV to update safe's

For my usecase I am trying to change the CPM that manages a couple safes, so I am using a csv for this only contains 1) the safe name, and 2) ManagingCPM.
When only using two two values in a one liner I am able to update the single safe but when I try to do this from a csv this is working, it looks like the script is assuming that I want to update the members of the safe. As there are no columns/headers in the csv for these fields a default value of 'False' is being used.
As values are now entered in for these permission fields when the call is made back to the vault it now also expects the 'MemberName' to be part of the call as we have included information about the permissions that need to be set.
Ideally when importing the csv and setting values, if the 'MemberName' is empty them the other values should be ignored. and not added to the call with default values.

Thanks for the info @NathTheDude
I have updated the script in the Debug branch for you to test again (see the commit reference above)
Could you please let me know if it works?
Thanks,
Assaf

@AssafMiron thanks, thats great.
This line just needs to be updated from:
numVersionRetention==$line.numVersionRetention;
to
numVersionRetention=$line.numVersionRetention;

Thanks a lot @NathTheDude
Did the change and merged to main :)
Thanks again!


LAB14B: Additional instructions request in Lab 14B to avoid project creation errors caused by extensions not  being installed.

Contact Details
No response
What happened?
Exercise : 00
Task: 01
Step: 06
Description of issue:
In Lab 14B (possibly others) we seem to receive a consistent error behavior caused because Extensions are not installed by default, and the existing 'Note' In case the process fails, navigate to your DevOps organization, delete the project, and try again forces students to encounter the error, delete the project, and then have to recreate the project when we may be able to include instructions to proactively avoid it.
Repro steps:

I encounter this issue using both DevOps Orgs created using Azure Passes as well as ALH/Cloudslice accounts.
Note that this error occurs in addition to the error referenced here - https://github.com/MicrosoftLearning/AZ400-DesigningandImplementingMicrosoftDevOpsSolutions/issues/207

Start Lab 14B, create new Azure DevOps Org.
Configure workaround referenced in #207 so as to avoid that issue.
Proceed with Task 1 to Step 6, and despite selecting the checkbox we still receive an error on 'Create Project':

If we check our Organization at this point, we will see the project has been created, and both Extensions will be installed. But, since we received an error on the Create Project, does this mean we need to create the project once more?  Even with the error, would the project work if we ran through the steps?
Even if the project would work OK at this point, many Students and even Instructors will not like having seen the error and will instead delete the project, and then re-run it so that - now the Extensions are installed - the final project creation attempt will be fully successful:

Instead, would it be possible to slightly re-work Step 6 from this:

Back on the Create New Project page, if prompted to install a missing extension, select the checkbox below the Replace Tokens and Terraform labels and click Create Project.

To something like this:

Back on the Create New Project page, if prompted about missing extensions, select the checkbox and then right-click and Open link in new tab for both Replace Tokens and Terraform. In each new browser tab, click the Get it free button, click Install for your organization, and finally return to your original Azure DevOps Demo Generator tab and click Create Project.

This would avoid errors + time wasted deleting projects and re-creating them a second time.
Lab
Lab 14b Automating infrastructure deployments in the Cloud with Terraform and Azure Pipelines
Relevant screenshots
No response
Do you want to help us? 👏

[ ] Create a Pull Request by following this project's Contribution Guide

To answer your question 4: I have had the same error message last week and it tells you that the release pipeline could not be created. So, the tasks in that lab could not be completed. I might have run into the exact same issue that you described, but instead imported on older version of the release pipeline. When I tried the next morning again, the error did not occur. I will watch out for this to happen during this week's training delivery.

https://github.com/microsoft/AzureDevOpsDemoGenerator/issues/599

issue has been closed in https://github.com/microsoft/AzureDevOpsDemoGenerator/issues/599


Add More Paragraphs for Typing Practice ✨

Add More Paragraphs for Typing Practice  int the public/data/paras.json
A small paragraph is also a big contribution!! 😇
Para Format
{
"title": "title of the paragraph", // string
"description": "paragraph description", //string
"text": "paragraph text", // string
"time": "time limit in seconds", // number
"resources": "resource link" // string
}

Thank you very much for taking your time and contributing in out project 🤗

Hi @iamBijoyKar  please assign this to me , I also created a PR that adds more paragraph examples


no quotes in HTML

When building, the result index.html doesn't have any quotes.
It works fine when running the production files locally, but when deploying to Firebase I get a number of these errors:
Unexpected token <

To fix this I had to manually add quotes on all the attributes...
Is there an option to enable those quotes on the building process?

If anyone stumbles upon this, I fixed it by modifying webpack.prod.conf.js.
      minify: {
        removeComments: true,
        collapseWhitespace: true,
        removeAttributeQuotes: false
      },


New Detection - KrbRelayUp Tool

Required items, please complete
Change(s):
Create New rule to detect service creation from KrbRelayUp tool
Reason for Change(s):
New rule to detect service creation from KrbRelayUp tool
Version Updated: 1.0
Required only for Detections/Analytic Rule templates
Testing Completed:
Tested on event with sigma rule
Checked that the validations are passing and have addressed any issues that are present:
See guidance below
References: https://github.com/Dec0ne/KrbRelayUp

This detection is related with this article.
https://www.microsoft.com/security/blog/2022/05/25/detecting-and-preventing-privilege-escalation-attacks-leveraging-kerberos-relaying-krbrelayup/