August 2024 - openstack-discuss - lists.openstack.org

Report a potential risk of secret leakage in project(murano)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(murano), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, murano. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(masakari)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(masakari), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, masakari. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(zun)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(zun), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, zun. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(refstack)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(refstack), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, refstack. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(castellan)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(castellan), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, castellan. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(ceilometer)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(ceilometer), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, ceilometer. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

Report a potential risk of secret leakage in project(monasca_api)
by kellanzchow＠gmail.com 13 Aug '24

13 Aug '24

Dear developers of the project(monasca_api), We are software security researchers, currently conducting research on secret detection and leakage risk within the open-source ecosystem. In our analysis, we identified potential secret leakage risks in your project, monasca_api. We provide the detail of our findings in the attachment, which allows you to locate the potential leaked secrets. Below is an interpretation of the attached data: { 'file': '', #The file containing the secret #The project name, version or commit_hash may be reflected in the file path 'line_start': 1, #location: Start line of the secret 'line_end': 28, #location: End line of the secret 'col_start': 1, #location: Start column of the secret 'col_end': 1, #location: End column of the secret 'index_start': 0, #location: Start index of the secret 'index_end': 1675, #location: End index of the secret } Declaration: we hereby declare that we have *NOT* conducted any verification test or exploit on the identified secrets. we plan to publish related research papers in the future, and the relevant content MIGHT BE ACCESS TO THE PUBLIC due to the 90-day disclosure policy. Some advise: 1. If the leaked secret is sensitive and still valid, invalid and rotate the secret immediately. 2. Some secrets seem to be used only in testing environment. Although probably harmless, it is considered bad practices to include secrets for test environment in release builds. Best regards,

1 0

[Nova][Keystone] Instance boot fail if user has many roles
by Masahito Muroi 13 Aug '24

13 Aug '24

Hi Nova and Keystone folks, I'd like to your feedback for the bug[1] and the commit[2]. We use Keystone as company internal role management system and hit the issue frequently. The commit is to change instance_system_metadata table schema, but it could be too big change only for the long role list. Another idea I can imagine is to introduce "store_boot_roles" boolean configuration to store the boot_roles or not. IIUC, the boot_roles is used only for a specific vendor data in the metadata api. If there is another good value to store from Keystone side, I'm happy to use the value instead of role name, too. 1. https://bugs.launchpad.net/nova/+bug/2075100 2. https://review.opendev.org/c/openstack/nova/+/925163 thank you, Masahito

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-7)
by Goutham Pacha Ravi 13 Aug '24

13 Aug '24

Hello Stackers, As we count down to the final release of OpenStack's 30th version [1], it's been another busy week across our community. Over the past week, the Technical Committee has merged several governance proposals, with a focus on leadership changes in preparation for the upcoming OpenStack election season. Project teams following a Distributed Project Leadership model (DPL) [2] were required to reassert their liaisons within the past week or elect a new PTL during the upcoming elections. The nomination period for Project Team Leads (PTLs) and the OpenStack Technical Committee will begin at 23:45 UTC on August 14, 2024. If you haven't already done so, please confirm your eligibility to vote in these elections by navigating to: https://civs1.civs.us/cgi-bin/opt_in.pl We are currently vetting runtimes for the upcoming 2025.1 ("Epoxy") release [3]. Please note that this will be a Skip-Level Upgradable (SLURP) release [4], meaning upgrades are supported from the 2024.1 ("Caracal") release to the 2025.1 ("Epoxy") release and from the 2025.1 ("Epoxy") release to the 2026.1 ("G") release. This also means that a wider range of distributions and Python versions will be tested within the community for this release. === Weekly Meeting === The last Technical Committee weekly meeting was primarily held over video [5], with notes taken in IRC [6]. We discussed several topics concerning gate health, noting that the recent end-of-life transition of CentOS 8 Stream has rendered the gate unstable across the stack. Several project teams had to find suitable alternatives to keep testing older branches or specific features on this distribution. Members noted that Rocky Linux has been relatively stable and may be a viable alternative for those still seeking a replacement. The OpenDev infrastructure team has freed up space and resources to accommodate mirrors for Rocky Linux. Your help is most appreciated if you're motivated to enable this in CI. We also discussed the upcoming elections and improvements to the election tooling. Several ideas were shared to prevent situations where projects lack a PTL candidate by the end of the nomination period. You'll hear more about these in the coming weeks. The next OpenStack TC weekly meeting is today, August 13, 2024, at 18:00 UTC. It will be hosted on OFTC in the #openstack-tc channel. The agenda has been shared on the meeting wiki [7]. I hope you'll join us. === Governance Proposals === ==== Merged ==== - Update criteria for inactive projects to become active again | https://review.opendev.org/c/openstack/governance/+/921500 - Reset the DPL model for the Freezer project | https://review.opendev.org/c/openstack/governance/+/925830 - Re-initiate the DPL model for the Freezer project | https://review.opendev.org/c/openstack/governance/+/925997 - Reset the DPL model for the Watcher project | https://review.opendev.org/c/openstack/governance/+/925831 - Reset the DPL model for the Release Management project | https://review.opendev.org/c/openstack/governance/+/925832 - Add Release Management DPL and liaison names | https://review.opendev.org/c/openstack/governance/+/926055 ==== Open for Review/Discussion ==== - Opt-in to the Oslo DPL model for the 2025.1 cycle | https://review.opendev.org/c/openstack/governance/+/926154 - Reset the DPL model for the Oslo project | https://review.opendev.org/c/openstack/governance/+/925834 - Define testing runtime for the 2025.1 release | https://review.opendev.org/c/openstack/governance/+/926150 - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Inactive state extensions: Monasca | https://review.opendev.org/c/openstack/governance/+/923919 - Update DPL model reset steps | https://review.opendev.org/c/openstack/governance/+/925926 === Upcoming Events === - August 14, 2024: Nominations open for 2025.1 OpenStack PTL + TC elections - August 16, 2024: Call for Proposals due for OpenInfra Days NA [8] - August 24, 2024: OpenInfra Days, Vietnam: https://2024.vietopeninfra.org/ - August 29, 2024: Dalmatian-3 milestone - September 3, 2024: OpenInfra Summit Asia, Suwon Thank you for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Distributed Project Leadership: https://governance.openstack.org/tc/reference/distributed-project-leadershi… [3] Testing runtimes for the 2025.1 release: https://review.opendev.org/c/openstack/governance/+/926150 [4] Skip-Level Upgradable releases (SLURP): https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad… [5] TC Meeting Video Recording, 2024-08-06: https://www.youtube.com/watch?v=HZhY9pxezWo [6] TC Meeting IRC Log, 2024-08-06: https://meetings.opendev.org/meetings/tc/2024/tc.2024-08-06-18.00.log.html [7] TC Meeting, 2024-08-13: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [8] CFP OpenInfra Days, NA: https://docs.google.com/forms/d/1U3TokM5QWTe9_MJvKbOiDc_cNNW_LlFpOL3t-Loib1…

1 0

Re: [legal-discuss] [Kolla] Re: LICENSE question - Openstack Masakari
by Michal Arbet 13 Aug '24

13 Aug '24

Adding openstack discuss mailing list [Kolla] On Mon, Aug 12, 2024, 22:11 <wes(a)openinfra.dev> wrote: > After consulting foundation legal counsel, this type of integration should > not be a problem from a licensing perspective as long as no BSL licensed > code is added into OpenStack code and as long as use of the HashiCorp > product remains optional. > _______________________________________________ > legal-discuss mailing list -- legal-discuss(a)lists.openstack.org > To unsubscribe send an email to legal-discuss-leave(a)lists.openstack.org >

1 0