- openstack-discuss - lists.openstack.org

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

[packing]Does the OpenStack repository break overall system compatibility
by 韩光宇 12 Aug '24

12 Aug '24

Hello, As an OpenStack operator who is also involved in packaging OpenStack, I've recently encountered some confusion regarding the packaging of OpenStack. From what I've gathered, Red Hat, SUSE, and Ubuntu package OpenStack in such a way that a single OS version can support multiple OpenStack versions. Each OpenStack version corresponds to its own separate repository (please correct me if I'm mistaken). I'm trying to understand the implications this packaging approach might have on system compatibility and maintenance. Such as, could this lead to the following scenario: The system repository has package A==1.0, The OpenStack repository has package A==2.0. After installing A==2.0 from the OpenStack repository, package B (which depends on A<=1.0) from the system repository can no longer be installed. Does this mean that the OpenStack repository breaks overall compatibility? My understanding of packaging is not very deep, so I would greatly appreciate any guidance or insights you can provide on this matter. Looking forward to your insights. Best regards, Han Guangyu

3 2

[cinder] Deadlock found when trying to get lock; try restarting transaction
by Eugen Block 12 Aug '24

12 Aug '24

Hi, in a customer cluster (Victoria, Galera cluster on 3 control nodes) we're seeing failing pipeline deployments from time to time when cinder is instructed to create multiple volumes at once. This is the error message: ---snip--- 2024-08-12 15:01:34.762 33307 WARNING oslo_db.sqlalchemy.exc_filters [req-aa5505d3-167a-4096-9311-36b10deebcc1 049f5ea05bd14c019aeab37d3cff4ffc ed22c592548e4903b9af541bb158c6fe - - -] DB exception wrapped.: sqlalchemy.exc.ResourceClosedError: This Connection is closed ... 2024-08-12 15:01:34.762 33307 ERROR oslo_db.sqlalchemy.exc_filters pymysql.err.InternalError: (1213, 'Deadlock found when trying to get lock; try restarting transaction') ... 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server File "/usr/lib64/python3.6/site-packages/sqlalchemy/engine/base.py", line 476, in _revalidate_connection 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server raise exc.ResourceClosedError("This Connection is closed") 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server sqlalchemy.exc.DBAPIError: (sqlalchemy.exc.ResourceClosedError) This Connection is closed 2024-08-12 15:01:34.766 33307 ERROR oslo_messaging.rpc.server (Background on this error at: http://sqlalche.me/e/13/dbapi) ---snip--- I found this bug [1] with a fix for Pike, so Victoria already has that fix, but the error still blocks some deployments, leaving volumes in "creating" state which has to be cleaned up manually. I can't find much else on this, am I missing something? Any pointers would be highly appreciated! Thanks! Eugen [1] https://bugs.launchpad.net/cinder/+bug/1789106

3 5

Assistance Needed with FWaaS Configuration in Kolla Ansible 2023.1
by Thamanna Farhath 12 Aug '24

12 Aug '24

Hello openstack community, I am currently working on integrating FWaaS V2 into my OpenStack deployment using Kolla Ansible 2023.1. Following the guidelines provided, I attempted to backport the changes from the following reviews: https://review.opendev.org/c/openstack/kolla-ansible/+/914854 https://review.opendev.org/c/openstack/kolla/+/914855/6 While I successfully made the necessary changes to each file in the first review, I encountered an issue with the second review. Specifically, the following files are missing from my environment: docker/horizon/extend_start.sh kolla/common/sources.py I am unsure why these files are missing and how I can resolve this issue to complete the backport process. Could you please provide guidance on how to address this problem? Any assistance or pointers would be greatly appreciated. Thanks in advance Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0