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

[publiccloud-sig] Reminder - next meeting August 21st - 0700 UTC
by Felix Kronlage-Dammers 19 Aug '24

19 Aug '24

Hi everyone, This Wednesday (August 21st) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig <https://meetpad.opendev.org/publiccloud-sig> See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG <https://wiki.openstack.org/wiki/PublicCloudSIG> See you on Wednesday! felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[cinder] Instance Volume Issue After Restarting tgtd Container During Upgrade
by Vahideh Alinouri 19 Aug '24

19 Aug '24

Hi Everyone, I'm currently upgrading an OpenStack deployment that was set up using Kolla-Ansible. I'm currently on Kolla version 14.8 (Yoga) and I am trying to upgrade to (Latest Yoga) 14.11, to eventually upgrade to the Zed release. During the upgrade process, I encountered an issue with the compute node that uses the Cinder LVM backend, which the instances rely on. Restarting the tgtd container caused the connection between the iscsid container and tgtd to be lost. In the Nova compute logs, I found the following error: Stderr: 'blockdev: cannot open /dev/sdb: No such device or address\n' Because of this, the instance transitions to an error state. I also observed this error in the tgtd container: login failed ISCSI_CONN_STATE_IN_LOGIN/R_STAGE_SESSION_REOPEN 500 10:18 Kernel reported iSCSI connection 6:0 error (1019 - ISCSI_ERR_XMIT_FAILED: Transmission of iSCSI packet failed) state (2). When I check the iSCSI session with the following command, it shows that the session is established: iscsiadm --mode session However, when I run the following command on the compute host (which handles the Cinder LVM backend via iSCSI), no output is returned: tgtadm --lld iscsi --op show --mode target I tried logging out and logging back into the session, but the logout operation failed! Here is my cinder.conf file on the compute host: [os-compXXXX-nvme] volume_group = vgnvme volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver volume_backend_name = os-compXXXX-nvme target_helper = tgtadm target_protocol = iscsi lvm_mirrors = 0 lvm_max_over_subscription_ratio = 1.0 The operating system on the compute node is Ubuntu 20.04. After further investigation, I found a temporary workaround to bring the instance back to an active running state: 1. Power off the compute node. 2. Evacuate the node (it gets stuck in rebuild, but that's okay). 3. Power on the compute node. 4. Reset the instance state to "active." 5. Check the volume status and update it if it's not in the "in-use" state. 6. Perform a hard reboot of the instance. 7. Restart the tgtd container. However, this is only a temporary solution. When I attempt to upgrade to the next version, I encounter the same issue again. Is there anything specific I should consider? Could this be a bug? I would greatly appreciate your help.

1 1

[MAGNUM] Fedora Core OS include NVIDIA GPU drivers
by Oliver Weinmann 19 Aug '24

19 Aug '24

Hi all, I'm running OpenStack 2023.2 (Bobcat) deployed with Kolla-Ansible. Currently I'm struggling to get the NVIDIA drivers to work in a FCOS 35 image. I know FCOS 35 is EOL and outdated, but for a K8s 1.21.11 cluster it is the only version that still works with Magnum. So far I managed to get the GPU Passthrough working for two NVIDIA Tesla T4 GPUs. I have attached the GPUs to an Ubuntu instance and ran geekbench without any issues. Then I tried to install the latest NVIDIA drivers in FCOS 35 by running: sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$ (rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$ (rpm -E %fedora).noarch.rpm systemctl reboot rpm-ostree install --apply-live akmod-nvidia akmods pciutils rpmdevtools xorg-x11-drv-nvidia-cuda It fails on: rpm-ostree install --apply-live akmod-nvidia akmods pciutils rpmdevtools xorg-x11-drv-nvidia-cuda error: Cannot download rpm-build-libs-4.17.0-4.fc35.x86_64.rpm: All mirrors were tried; Last error: Status code: 403 for https://fedoraproject-updates-archive.fedoraproject.org/fedora/35/x86_64/rp… I guess the binaries are no longer hosted? Running the same on FCOS 36 and latest FCOS 40 works fine. Next I have taken new images from the FCOS instances with the NVIDIA driver. openstack server image create --name fedora_coreos_36_nvidia_cuda fedora_coreos_35_latest_no_update --wait This takes ages but anyway I can successfully deploy new instances from the images with my gpu flavor and the GPU is working fine. Again tested with geekbench. But now when adding new K8s worker nodes in a fresh nodegroup on an existing K8s 1.21.11 cluster the nodes are not joining the cluster: openstack coe nodegroup create \ --node-count 1 \ --role worker-gpu \ --flavor gpuflavor \ --image fedora_coreos_36_nvidia_cuda \ $CLUSTER_ID worker-gpu I have tested the latest available images of FCOS36 and they work fine, so something must be wrong with how I created the new image. Is there some magic that needs to be done? I'm also not sure if this is the best way of doing this. Maybe there is already a ready FCOS image with nvidia drivers? I can find lots of outdated information on the internet. Generally I tend to use Vexxhost CAPI from now on, which works great. This is really just a one off attempt to have a working NVIDIA T4 GPU in a K8s 1.21.11 cluster. Best Regards, Oliver

5 16

[template][cinder]Dell powerflex: cinder-plugin-ceph-tempest cannot be deployed successfully
by cuiye.liu＠dell.com 19 Aug '24

19 Aug '24

Because the https://zuul.opendev.org/t/openstack/build/cc284844b56c41b3aa58669036f25a71 is failed. I deploy a local environmet according the guide https://github.com/openstack/devstack-plugin-ceph. But it is failed, and the error is as following: +inc/python:pip_install:151 set +o xtrace Using python 3.10 to install /opt/stack/keystone +inc/python:pip_install:219 env http_proxy= https_proxy= no_proxy= PIP_FIND_LINKS= /opt/stack/data/venv/bin/pip install -c /opt/stack/requirements/upper-constraints.txt -e /opt/stack/keystone Obtaining file:///opt/stack/keystone Preparing metadata (setup.py) ... error error: subprocess-exited-with-error × python setup.py egg_info did not run successfully. │ exit code: 1 ╰─> [1 lines of output] ERROR: Can not execute `setup.py` since setuptools is not available in the build environment. [end of output] note: This error originates from a subprocess, and is likely not a problem with pip. error: metadata-generation-failed × Encountered error while generating package metadata. ╰─> See above for output. note: This is an issue with the package mentioned above, not pip.

1 0

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

18 Aug '24

Hello Stackers, Greetings from the OpenStack Technical Committee! We're two weeks away from freezing the 2024.2 release for feature changes across most service projects [1]. So the focus of these final few weeks has been on code reviews and testing. The community's election season is also underway. I hope you're able to carve out some time to consider submitting a nomination to be a Project Team Leader [2] or a member of the Technical Committee [3] this week [4]. Please feel free to ask questions on the #openstack-dev or #openstack-tc channels on OFTC. === Weekly Meeting === It was the usual order of business at the OpenStack TC meeting last week. This meeting was held over IRC and the log is available on eavesdrop [5]. The discussion was focussed on gate stability, CI and infrastructure enhancements as well as the ongoing elections. Our call for help with Rocky Linux in the CI is being heeded. Thank you very much to the volunteers that are stepping up and the #opendev-infra team for coordinating this. Ghanshyam Mann (gmann) has proposed updates to the runtimes for Python and Operating System platforms for 2025.1 ("Epoxy") [6]. I hope you'll be able to review this proposal. We tabled a discussion regarding testing/shipping binaries with non-OSI compatible licenses to the next meeting. The next IRC meeting of the OpenStack TC is on Tuesday, 2024-08-20. We hope you'll be able to join us on the #openstack-tc channel on OFTC. Please find the agenda in the meeting wiki [7]. Do note that you can always propose discussion items to this agenda, be sure to leave an IRC nick that we can call upon to lead/assist with the discussion. === Governance Proposals === ==== Open for review/discussion ==== Define testing runtime for 2025.1 release | https://review.opendev.org/c/openstack/governance/+/926150 Inactive state extensions: Monasca | https://review.opendev.org/c/openstack/governance/+/923919 Opt-in the oslo DPL model for 2025.1 cycle | https://review.opendev.org/c/openstack/governance/+/926154 Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 Update DPL model reset steps | https://review.opendev.org/c/openstack/governance/+/925926 === Upcoming Events === 2024-08-24: Open Infra Days, Vietnam: https://2024.vietopeninfra.org/ 2024-08-28: Nomination period closes for 2025.1 OpenStack PTL+TC elections 2024-08-29: Dalmatian-3 milestone 2024-09-03: Open Infra Summit Asia, Suwon 2024-09-06: Open Infra Days, Tokyo === How to contact the TC === You can reach out to the TC in multiple ways: 1. Email: you can send the email with tag [tc] on this email list. 2. Ping us using 'tc-members' keyword on #openstack-tc IRC channel 3. Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [7] Thank you very much 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] Becoming a PTL: https://docs.openstack.org/project-team-guide/ptl.html [3] OpenStack TC Charter: https://governance.openstack.org/tc/reference/charter.html [4] Combined PTL/TC 2025.1 cycle Election Nominations Kickoff https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] TC Meeting IRC Log, 2024-08-13: https://meetings.opendev.org/meetings/tc/2024/tc.2024-08-13-18.00.log.html [6] Proposal for testing runtimes for the 2025.1 release: https://review.opendev.org/c/openstack/governance/+/926150 [7] TC Meeting, 2024-08-20: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Eventlet and debugging
by engineer2024 18 Aug '24

18 Aug '24

Hi All, How many more releases are you planning to include eventlet in them ? Seems they are removing any support for further development according to their official website. So, is the community thinking of any alternatives ? Also, can someone write a small blog on how to use backdoor to debug the nova processes. That would be a great help until then.... Thanks elinux

7 16

[cinder][tempest] service_token_roles=admin unexpected behaviour
by Sven Springer 16 Aug '24

16 Aug '24

Hi, I have a question in regards to the service_token_roles setting in combination with an old vulnerability: I have a failing tempest test case, which is there to specifically test this vulnerability: https://lists.openstack.org/pipermail/openstack-announce/2023-May/002070.ht… I checked the cinder in our setup, and it contains the fix Test-reference: https://review.opendev.org/c/openstack/tempest/+/882876 Now I wonder if the test fails because in our setup, we set "service_token_roles = admin" for cinder, and the detach calls therefore being accepted (when the tempest tests expect them to be denied). Can someone confirm or deny this hypothesis? Best regards, Sven.

1 0

[release] Release countdown for week R-6, Aug 19-23
by Elõd Illés 16 Aug '24

16 Aug '24

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various72 library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on August 22nd, 2024. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2024.2 branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (August 29th, 2024) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, August 29th, 2024. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2024.2 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2024.2 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2024.2 Dalmatian will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 22nd, 2024 (R-6 week) Client library freeze: August 29th, 2024 (R-5 week) Dalmatian-3 milestone: August 29th, 2024 (R-5 week) Cycle Highlights Due: September 5th, 2024 (R-4 week) 2024.2 Dalmatian final release: October 2nd, 2024 Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron] Drivers meeting canceled tomorrow, Friday, August 16th
by Brian Haley 16 Aug '24

16 Aug '24

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is no agenda and two members cannot attend. There is one item for next week's meeting so far: * [RFE] Allow binding Security Groups to Network https://bugs.launchpad.net/neutron/+bug/2075955 Feel free to add any comments to the bug so the submitter can try and answer them before then. Thanks! -Brian

1 0

Connectivity Issues with Beluga Cloud
by Zil Pavdighada 15 Aug '24

15 Aug '24

Hello, I hope this email finds you well. I am currently working on a cloud project using the Beluga cloud platform. I have set up an Apache server on a VM and am hosting a website through MobaXTerm. While SSH is working fine, I am unable to connect to the VM using either the floating (public) or private IP address. I have already troubleshooted my network and MobaXTerm without success. I am wondering if the issue might be related to the cloud project itself. Any assistance you can provide would be greatly appreciated. Thank you. Zil Pavdighada

4 4

[kolla] LICENSE answer from
by Michal Arbet 15 Aug '24

15 Aug '24

Hello Koalas, I would like to share with you a statement where I discussed the possibility of adding orchestration for Konsul and similar projects (like Vault, for example, for Barbican) into the Kolla and Kolla-Ansible code – and whether this contradicts the conditions of the OpenDev community... TLDR - there is no problem to add this piece of code as it still remain optional and it's not break any license Last message in list: "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." https://lists.openstack.org/archives/list/legal-discuss@lists.openstack.org… Thank you very much Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

2 1

[Cinder][Glance][Image Encryption] Discussion about the handling of images with old "cinder_encryption_*"-parameters
by Josephine Seifert 15 Aug '24

15 Aug '24

Hi everyone, because we will rename some parameters in encrypted images, we should discuss the transition from the old Glance image metadata naming (|cinder_encryption_*|) to the new one (|os_encrypt_*|). Glance and Cinder are affected: * |*_key_deletion_policy| is used to delete Barbican secrets; if Glance and Cinder use different namings here, secret is not properly deleted * if Cinder still uses |cinder_encryption_*|, secret consumers are not registered as the image is not detected as encrypted by Glance * Old image with old parameters may not be detected anymore by Cinder, as soon as the new code is rolled out It may be advisable to introduce a deprecation period and make Glance and Cinder still accept the old metadata names when parsing image metadata. The image encrpytion pop-up team is meeting next Monday 13 UTC in IRC (in openstack-meeting). We can discuss it then, please join the meeting. greetings Luzi

1 0

[charms] Proposing Jadon Naas and Myles Penner for OpenStack Charms core
by James Page 14 Aug '24

14 Aug '24

Hi everyone I'd like to propose Jadon Naas and Myles Penner for the OpenStack Charms core development team. Jadon has been contributing for over 12 months, providing reviews and direct contributions in a number of areas including figuring out a niggly configuration issue in the OIDC support in Keystone. Myles has been contributing for about 6 months - I'd highlight his work on owning the implementation of audit middleware support in the charms in support of his proposal to the core team. Thank you both for your contributions to the project! Regards James

2 2

networking-onos plugin
by Ganesan, Sathya 14 Aug '24

14 Aug '24

Good Day, Is there an alternative integration available for ONOS and Openstack since networking-onos is archived? Sathya Ganesan Geico Tech | Data Center Core Network Engineering - SDN | sganesan(a)geico.com<mailto:sganesan@geico.com> | 240.478.2121 | M-F 9a-5:30p EST Sensitivity: Company-Internal ==================== This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message.

2 2

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

14 Aug '24

Hi Nova and Keystone folks, I'd like to get 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 by 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

2 3

[kolla] IRC meeting cancelled today
by Bartosz Bezak 14 Aug '24

14 Aug '24

Hello, Unfortunately, due to the unavailability of core team members, we need to cancel today’s Kolla IRC meeting. Apologies for the late notice. Best regards, Bartosz Bezak

1 0

[Glance] Cancelling Weekly Meeting (Aug 15)
by Pranali Deore 14 Aug '24

14 Aug '24

Hello, Cancelling tomorrow's weekly's meeting as 15th August is National Holiday in India and most of the team members will not be around. See you next week!! Thanks, Pranali Deore

1 0

[rabbitmq] Maximum Number of Sessions (8192) Reached
by Eugen Block 14 Aug '24

14 Aug '24

Hi *, I can't seem to find much about rabbitmq and logind, so I wanted to ask the list if anyone has encountered the same and if so, how they dealt with it. We're supporting a Victoria cluster (installed with our own deployment method) mostly controlled by pacemaker. And on the rabbit master node I see this warning constantly: ---snip--- 2024-07-29T14:09:23.552576+02:00 control01 su: pam_unix(su:session): session opened for user rabbitmq by (uid=0) 2024-07-29T14:09:24.450657+02:00 control01 su: pam_unix(su:session): session closed for user rabbitmq 2024-07-29T14:09:24.500356+02:00 control01 su: (to rabbitmq) root on none 2024-07-29T14:09:24.502370+02:00 control01 su: pam_systemd(su:session): Failed to create session: Maximum number of sessions (8192) reached, refusing further sessions. 2024-07-29T14:09:24.502681+02:00 control01 su: pam_unix(su:session): session opened for user rabbitmq by (uid=0) 2024-07-29T14:09:25.565203+02:00 control01 su: pam_unix(su:session): session closed for user rabbitmq 2024-07-29T14:09:25.609613+02:00 control01 su: (to rabbitmq) root on none ---snip--- Looking into loginctl list-sessions, almost all of them belong to rabbitmq and they have a very old timestamp (2023). I'm aware of older systemd versions which can't handle closing sessions correctly [0], but we can't upgrade at this time. Would enabling "linger" fix this (loginctl enable-linger rabbitmq) after a reboot? During the next maintenance window I would reboot control01 and watch how the other control nodes behave wrt rabbit login-sessions. But I'm wondering if somebody already has dealt with this? Thanks for any pointers! Eugen [0] https://www.suse.com/support/kb/doc/?id=000020549

1 2

[manila] Cancelling Aug 15 weekly meeting
by Carlos Silva 14 Aug '24

14 Aug '24

Hello Zorillas and interested stackers, I would like to cancel this week's weekly meeting. Several people from the audience have holidays in their countries/cities or are on PTO. We'll return to our regular weekly meetings on August 22nd. Thank you, carloss

1 0

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

13 Aug '24

Dear developers of the project(cinder), 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, cinder. 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,

3 2

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

13 Aug '24

Dear developers of the project(barbican), 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, barbican. 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,

3 3

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

13 Aug '24

Dear developers of the project(manila_ui), 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, manila_ui. 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(manila)
by jiawei_zhou＠seu.edu.cn 13 Aug '24

13 Aug '24

Dear developers of the project(manila), 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, manila. 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(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