Friday, June 5, 2026

[SECURITY] Security vulnerability in CI reported, resolved without incidence

Dear GNU Radio community, today, we received a security advisory via the contact method we offer in a canonical place [1], alerting us to the following: The github CI workflow that can be used to re-render the conda template gets triggered and executed without checking that the author of the triggering PR has CI privileges. (For the CI that gets run when you open a PR, you need to be trusted, or else a maintainer needs to click on "Approve CI run" every time you post or update a CI; this is not true for the github "issue_comment" trigger, which honestly is, in line with the rest of github CI's documentation style, something you can infer with enough experience, from sources outside Github documentation. We didn't infer that, and we wonder why there are action security controls that do not apply to all ways to trigger actions. Still, it's our responsibility to keep things safe, and assuming controls work without checking seems to be something we need to add to our list of things to do when working with public CI.) That would have allowed an attacker to open a PR that does something nefarious (attack webservers, mine cryptocurrency, exfiltrate CI secrets, modify commits/source code). We received this report from Wang-Meimei, for which we are very thankful. Steps taken: 1. simply removed that workflow. That makes it impossible to trigger from PRs, even should they add it back: it needs to exist on the main branch to work. I have not been able to get the workflow to function correctly in the last six months, so functionally, this is not a restriction of our abilities. 2. investigated workflow runs of the past year. No execution of that workflow, aside from my own, have been found. There have not been any inconsistencies of the main branch history with local copies, so we can preclude any code modifications. 3. Started a review of the repository action secrets stored in github. As mentioned in 2., we are certain enough this was not exploited, but we are still working to rotate secrets, and flush caches where applicable. ("abundance of caution", but really, we should just be doing that in a situation like this, without needing to think about it.) Special thanks, again, go out to Wang-Meimei, who's been very helpful in their reporting. Best regards, Marcus Müller [1] as described in RFC 9116: https://gnuradio.org/.well-known/security.txt

Posted by at No comments:

IEEE Aerospace Conference 2027

Hello,

 

I am chairing the Software Defined and Cognitive Radio session at the upcoming IEEE Aerospace Conference (http://www.aeroconf.org, https://aeroconf.org/cms/content_attachments/26/download).  This large conference will take place March 6-13, 2027 in Big Sky, Montana.  The conference provides a world-class technical program and provides excellent opportunities for both networking and recreation. This is one of the few conferences where SDR can be put in the context of a complete system and can be applied to new missions and concepts of operations.

 

Last year there were a few papers dealing with application of machine/deep learning to radio design.  I hope to see even more next year!

Abstracts are due soon, but I can take them later as well, while the full paper is due end of October.  This session will focus on flexible radio architectures, including the use of GPPs, GPUs,  and FPGAs.  Reports of existing systems and testbeds are of significant interest.  This year I’d like to introduce work related to machine learning as applied to wireless communications.

 

Please forward this to your friends and colleagues working in the areas of SDR, ML for signal processing, and cognitive radio.


Regards,

Eugene.



Eugene Grayver, Ph.D.
Principal Engineer
310-336-1274
Posted by at No comments:

Thursday, June 4, 2026

Accumulating into output_items[0] across multiple general_work()

Hi all,

I have a block whose output items are running averages over a long integration (for the sake of simplicity say a power spectrum accumulated over millions of FFT frames, way too many to hold as one input buffer).

The implementation that fell out naturally is: in general_work(), add the next batch of partial contributions directly into output_items[0][n_emitted], return 0 while the integration is still incomplete, and only return n_emitted > 0 when one or more integrations are done. It's pretty tempting to do as this would practically avoid an extra memory allocation for an internal buffer and a memcpy back to output_items when accumulation is ready.

However, this relies on the assumption that returning 0 leaves the write pointer unadvanced, so the next general_work() call sees the same memory at output_items[0][n_emitted] and I can keep adding into it. 

As far as I can tell, this works on current GR (no-op when produce_each(0) -> write pointer not updated), but it’s more like an implementation detail rather than it being documented as part of the scheduler API.

Two questions:
1) Is the "accumulate into output_items[0] across calls" pattern supported, or am I in undocumented/unidentified scheduler/buffer behavior territory?
2) If it's not supported, is there any reason beyond "no API guarantee”; e.g. would it break under certain custom buffers or futuristically GR4?

If the answer is just "use an internal buffer," happy to refactor.

Thanks!
Wael
Posted by at No comments:

Friday, May 29, 2026

Re: GR4 Updates and Dev Meeting — Thursday, May 28 at 12 PM ET

Thanks everyone who attended - we overviewed the state of the project, began organizing subgroups, worked through the scope of CI and target platforms, and discussed repo structure going forward.

We are going to meet more regularly on the 2nd and 4th Thursday of each month - 12 PM ET - mark your calendars:



Please also join us in the ongoing chat - where you will find the link to the meeting minutes


Josh

On Tue, May 26, 2026 at 8:51 PM Josh Morman (GNU Radio) <jmorman@gnuradio.org> wrote:
Greetings GNU Radio Community!

GR4 development is kicking into high gear. We are continuing our monthly development meetings - and may meet more often as needed - starting this Thursday, May 28, at 12 PM ET.

--- Joining info for Thursday
Video call link: https://meet.google.com/owd-bstv-xda
Or dial: ‪(US) +1 402-724-0159‬ PIN: ‪852 787 210‬#
More phone numbers: https://tel.meet/owd-bstv-xda?pin=1404845118840
---

Please come prepared to help us work out the remaining pieces to get to the 4.0.0 release.  We need help across block development, applications, examples, testing, documentation, and release readiness.

Also, the board wrote a statement last week about the importance of this community and stewardship of GR4 as the next evolution of the GNU Radio project.  So please take a look if you haven't already:


Hope to see you there.

Josh



Posted by at No comments:

Wednesday, May 27, 2026

GR4 Updates and Dev Meeting — Thursday, May 28 at 12 PM ET

Greetings GNU Radio Community!

GR4 development is kicking into high gear. We are continuing our monthly development meetings - and may meet more often as needed - starting this Thursday, May 28, at 12 PM ET.

--- Joining info for Thursday
Video call link: https://meet.google.com/owd-bstv-xda
Or dial: ‪(US) +1 402-724-0159‬ PIN: ‪852 787 210‬#
More phone numbers: https://tel.meet/owd-bstv-xda?pin=1404845118840
---

Please come prepared to help us work out the remaining pieces to get to the 4.0.0 release.  We need help across block development, applications, examples, testing, documentation, and release readiness.

Also, the board wrote a statement last week about the importance of this community and stewardship of GR4 as the next evolution of the GNU Radio project.  So please take a look if you haven't already:


Hope to see you there.

Josh



Posted by at No comments:

Tuesday, May 26, 2026

GSoC '26: Introduction and Project Kick-off

Hello everyone,

My name is Youssef, and I am very pleased to share that my project, "Graphical interoperability between CyberEther and GNU Radio", was accepted for GSoC26. I am incredibly excited about this opportunity.

I am relatively new to the RF and SDR world, but I have been learning a great deal over the past month. I have been meeting weekly with my mentors, Luigi and Håkon, during the community bonding period to discuss the project architecture and get up to speed.

I am very grateful to be a part of this community. Hopefully, by the end of the summer, I will have successfully integrated CyberEther's GPU-accelerated sinks into GNU Radio.

The official coding period starts today, and I will document my progress on a blog. I will set it up this week and share the link over at Matrix, would be very happy to receive any feedback from you all.

Best regards,
Youssef Mahmoud
Posted by at No comments:

NEWSDR 2026 in Two Weeks — June 4 & 5 — WPI in Worcester, Massachusetts, USA

The 16th annual New England Workshop on Software Defined Radio (NEWSDR) is only two weeks away!!

NEWSDR 2026 will be held on Friday June 5, with evening tutorials on Thursday June 4.

NEWSDR 2026 will be hosted in-person at Worcester Polytechnic Institute (WPI) in Worcester, Massachusetts.

Advance registration is free but required so that we can get a headcount.

For event details, latest updates, and registration, please visit:

https://newsdr.org/workshops/newsdr-2026/

We are also still welcoming poster presentations, and we encourage anyone interested to submit a poster for the event at the link below.

https://docs.google.com/forms/d/e/1FAIpQLScYvl_NpCt2RLHv7UoqGMy1APVh_3MfT5DZgoiknACl0ENliw/viewform

We look forward to seeing you at the event !!
Posted by at No comments:
Subscribe to: Posts (Atom)