pgjdbc/pgjdbc GitHub issues and pull requests (mirror)
help / color / mirror / Atom feed[pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
26+ messages / 4 participants
[nested] [flat]
* [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 13:17 "davecramer (@davecramer)" <[email protected]>
0 siblings, 0 replies; 26+ messages in thread
From: davecramer (@davecramer) @ 2023-06-29 13:17 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 13:29 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 13:29 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
-1
I would instead remove the use of the property.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 13:30 "davecramer (@davecramer)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: davecramer (@davecramer) @ 2023-06-29 13:30 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> -1
>
> I would instead remove the use of the property.
It seems people are using it?
https://github.com/pgjdbc/pgjdbc/issues/2725
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 14:03 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 14:03 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
I think we should better add `Properties`-like constructor to `SingleCertValidatingFactory`.
The old configs will still work, however, newer clients should prefer using meaningful argument names than `sslfactoryarg`.
For instance, we could teach `SingleCertValidatingFactory` to fetch the property `tlsCertificate` or `SingleCertValidatingFactory.tlsCertificate`.
In other words, I mean something like
```diff
+ public SingleCertValidatingFactory(Properties info) throws GeneralSecurityException {
+ this(info.getProperty("SingleCertValidatingFactory.tlsCertificate"));
+ }
+
public SingleCertValidatingFactory(String sslFactoryArg) throws GeneralSecurityException {
if (sslFactoryArg == null || sslFactoryArg.equals("")) {
throw new GeneralSecurityException(GT.tr("The sslfactoryarg property may not be empty."));
}
```
Then the client code would be like
```java
PGProperty.SSL_FACTORY.set(properties, SingleCertValidatingFactory.class.getName());
// Something like that
properties.setProperty("SingleCertValidatingFactory.tlsCertificate", "file:...");
// or
SingleCertValidatingFactory.TLS_CERTIFICATE.set(properties, ...);
```
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 14:09 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 14:09 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Yet another possibility is to allow clients to pass `SockerFactory` instances via `sslfactory`, so the code could be
```java
PGProperty.SSL_FACTORY.set(properties, new SingleCertValidatingFactory("..."));
```
Of course, Java's `Properties` discourage passing non-string values, however, it seems to fit here.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 14:26 "sehrope (@sehrope)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: sehrope (@sehrope) @ 2023-06-29 14:26 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Adding support for the Property based constructor is fine for our own code, but needless breaking everybody else or giving deprecation notices for something that will not actually be removed because there is no replacement is not acceptable.
Again, the main use case of this property is that it is a **known** property that can coexist with our other properties. That's been part of the pgjdbc API for nearly two decades.
Maybe we should declare some other slice of the properties namespace that we will not touch, e.g. "client.XYZ" or "user.XYZ". That would allow someone to use those namespaced fields in their custom factories with the Property based constructor. But that's a separate exercise and there is no reason to break the String based constructor code even after we implement that. It's just breaking things with no worthwhile gain.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 14:32 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 14:32 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> Adding support for the Property based constructor is fine for our own code, but needless breaking everybody else
Could you please clarify how adding `Property` based constructor breaks everybody else code?
Property-based constructor would be a replacement for string-based one.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 14:40 "sehrope (@sehrope)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: sehrope (@sehrope) @ 2023-06-29 14:40 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Removing the string constructor breaks people's code. Adding the Property constructor by itself does not change anybody's existing usage so there's no inherent gain.
What's the point of adding it if you're not going to remove the other constructor?
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 15:02 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 15:02 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
If we add properties constructor, people might start using it, and it would be easier for them to configure, document, and understand.
For instance, `SingleCertValidatingFactory.tlsCertificate` property name would be much easier to find and understand in the documentation, internal wikis, emails, and StackOverflow than an obscure sslfactoryarg.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 15:17 "davecramer (@davecramer)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: davecramer (@davecramer) @ 2023-06-29 15:17 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
So the proposal is to leave the deprecation as it is and add a Properties based constructor?
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 15:26 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 15:26 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
>So the proposal is to leave the deprecation as it is and add a Properties based constructor?
That is my intention. I would like people to refrain from accidentally using sslsocketfactoryarg even though we will have to support it for the indefinite future.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 15:53 "jrobe (@jrobe)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: jrobe (@jrobe) @ 2023-06-29 15:53 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> > Adding support for the Property based constructor is fine for our own code, but needless breaking everybody else
>
> Could you please clarify how adding `Property` based constructor breaks everybody else code?
>
> Property-based constructor would be a replacement for string-based one.
Here's the thing; other users have no way of adding custom properties to DataSource-based connections if they're wrapped by some other datasource passing them down. E.g. we should either deprecate this and add a separate property recognized by BaseDataSource, or do what [sehrope](https://github.com/sehrope) recommends, which is to allow setting user.[x] properties, and support them in the BaseDataSource.
I have a custom SSLSocketFactory class, and to configure it I need to be able to have at least one BaseDataSource property that I can use that can be the argument(s) I need for that class.
I'm hitting this issue with the aws-advanced-jdbc-wrapper, which doesn't work well with Hikari unless it uses a DataSource (PGSimpleDataSource in this case). That wrapper takes in a properties argument that can be set, which is applied to the base data-source. Driver-based I can set whatever property I want, but when using a data-source I'm limited to what the getters/setters on the datasource have; which means I need SSLFactoryArg (or some equivalent) to setup my custom SSLFactory class.
1. Deprecating something that you plan on supporting forever isn't the right thing to do.
2. Having no alternative to have a DataSource support sending arguments to a custom SSLFactory and removing this will certainly break a bunch of code and also isn't the right thing to do.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:00 "jrobe (@jrobe)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: jrobe (@jrobe) @ 2023-06-29 16:00 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> If we add properties constructor, people might start using it, and it would be easier for them to configure, document, and understand.
>
> For instance, `SingleCertValidatingFactory.tlsCertificate` property name would be much easier to find and understand in the documentation, internal wikis, emails, and StackOverflow than an obscure sslfactoryarg.
It's strange to me that the solution to the problem is "add another property" instead of support the existing one. Especially when the initial argument for marking it as deprecated was "there are too many properties" https://github.com/pgjdbc/pgjdbc/issues/1293
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:18 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 16:18 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
>Deprecating something that you plan on supporting forever isn't the right thing to do.
What would you say about deprecated methods in `String` and/or `Thread.stop` / `Thread.suspend`?
They are depreacted for the very same reasons
```java
package java.lang;
public class String {
/**
* @deprecated This method does not properly convert bytes into characters.
* As of JDK 1.1, the preferred way to do this is via the
*/
@Deprecated(since="1.1")
public String(byte ascii[], int hibyte, int offset, int count) {
*/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:26 "jrobe (@jrobe)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: jrobe (@jrobe) @ 2023-06-29 16:26 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> What would you say about deprecated methods in `String` and/or `Thread.stop` / `Thread.suspend`? They are depreacted for the very same reasons
Deprecated because of a bug (doesn't properly convert bytes into characters), is different than the use-case here.
Since the BaseDataSource supports custom SSLFactories, and you've demonstrated a need to have arguments passed to those custom factories in your own SingleCertValidatingFactory, this property should live un-deprecated to support users to have an avenue of passing arguments to their own custom factories.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:31 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 16:31 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Thread.stop has no bugs. It was deprecated for other reasons
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:34 "jrobe (@jrobe)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: jrobe (@jrobe) @ 2023-06-29 16:34 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> Thread.stop has no bugs. It was deprecated for other reasons
Ok, that's tangential to this code review. And deprecation messages in Java's "Thread" class are different than this, because we (as developers) **know** that Java isn't going to just remove this, because they know that they can't break people's code. The problem with deprecation messages in other things (like the postgres library) is that we _don't_ know if deprecation means it's slotted for removal in the future, of if it's just not preferred. Not _preferred_ doesn't really warrant a deprecation tag for me; but perhaps a strongly worded java-doc.
My argument is since the BaseDataSource supports custom SSLFactories, and you've demonstrated a need to have arguments passed to those custom factories in your own SingleCertValidatingFactory, this property should live un-deprecated to support users to have an avenue of passing arguments to their own custom factories.
I need a way to do this in my code, and I'd prefer that way to not have a deprecation message and strike-through on the property name that I'm setting in this perfectly valid code (and a guarantee that when I update to some later postgres driver version that it won't all of a sudden disappear).
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 16:41 "sehrope (@sehrope)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: sehrope (@sehrope) @ 2023-06-29 16:41 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
To clarify I'm proposing:
1. Merge this PR so that the property is no longer deprecated. It's just noise for people using it and we're not going to remove it. There's nothing inherently broken about it and even changing the internal usage to use the Properties constructor does not change usage of the `sslfactoryarg` property itself. You still need that key to exist.
2. Separate discussion or PR to document a slice of the property namespace that could be leveraged by end users. Something they know will never conflict with a built-in property. Either something like `<custom-prefix>.YOUR_PROPERTY_HERE` or simply suggest that they use reverse DNS naming like Java packages and we promise never to touch anything outside of bare strings / org.postgresql. Either way that's a separate discussion then closing out this pointless deprecation.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 17:02 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2023-06-29 17:02 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> The problem with deprecation messages in other things (like the postgres library) is that we don't know if deprecation means it's slotted for removal in the future, of if it's just not preferred
Would you raise an enhancement request for `deprecation` feature in Java then?
The javadoc does clarify why `sslfactoryarg` is discouraged.
Unfortunately, Java does not have something like Kotlin's OptIn: https://kotlinlang.org/docs/opt-in-requirements.html.
Apparently, adding "notices in javadocs" does not help as people do not seem to follow them.
> and you've demonstrated a need to have arguments passed to those custom factories in your own SingleCertValidatingFactory
I do not think so.
SingleCertValidatingFactory can receive arguments with `Properties` just fine, and it does not require `sslfactoryarg`.
> this property should live un-deprecated to support users to have an avenue of passing arguments to their own custom factories
There should be a better way to pass custom properties than `sslfactoryarg`.
As it turned out, deprecating `sslfactoryarg` and still having it as the only way to configure `SingleCertValidatingFactory` was a mistake. However, it does not imply we must un-deprecate `sslfactoryarg` right away. We should rather add a possibility to instantiate `SingleCertValidatingFactory` with better API.
----
I have no issues with merging this PR, however, I would raise a new one that removes the usages of `sslfactoryarg` from pgjdbc code and deprecates the property again. Why discuss un-deprecating it?
That is exactly the reason I suggest we stop discussing "un-deprecation", and we should rather focus on the way **how** clients should pass extra properties.
I assume "un-deprecating and deprecating it again" would be pure noise, especially taking into account that we won't release pgjdbc in-between.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-06-29 17:34 "jrobe (@jrobe)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: jrobe (@jrobe) @ 2023-06-29 17:34 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> I do not think so.
SingleCertValidatingFactory can receive arguments with Properties just fine, and it does not require sslfactoryarg.
It does require that arg today; and no publicly settable property exists to configure it besides sslfactoryarg.
> There should be a better way to pass custom properties than sslfactoryarg.
I mean, this may be true; but why is sslfactoryarg so inherently bad? Since we can define our own SSLFactory to use, we should have a property that we can use to give context to our own SSLFactory class. We'd just be trading one property for another, the other one being whatever custom stuff is defined in a later PR.
> I have no issues with merging this PR, however, I would raise a new one that removes the usages of sslfactoryarg from pgjdbc code and deprecates the property again. Why discuss un-deprecating it?
That is exactly the reason I suggest we stop discussing "un-deprecation", and we should rather focus on the way how clients should pass extra properties.
> I assume "un-deprecating and deprecating it again" would be pure noise, especially taking into account that we won't release pgjdbc in-between.
This does indeed assume there's a simple answer to customer user properties; however I don't think that'll be as straightforward as you're making it out to seem; since BaseDataSource would need to have a way to hold all of these custom properties and send them around to the Driver, the SSLSocketFactory, and other classes. Can we please merge this PR and only deprecate it if there is indeed a workable other solution that is released later?
And removing usages of sslfactoryarg from pgjdbc code is not a valid reason for deprecation; since sslFactory is allowed to be any custom class and users still need a way to send in arguments to their custom class (and removing that existing constructor is a non-backwards compatible change which is a huge uplift for seemingly no reason). Deprecation should only happen if there's an alternate way to configure any custom SSLFactory (not just the SingleCertFactory).
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2023-07-03 14:57 "sehrope (@sehrope)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: sehrope (@sehrope) @ 2023-07-03 14:57 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Given the overwhelming feedback in favor of this, I'm going to merge this later today.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2025-01-23 13:24 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2025-01-23 13:24 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
After giving this some more time I am leaning towards we should indeed un-deprecate the property.
For the record the reasons are:
* We will not remove it in the nearest future, and `@deprecated` is not the way to convey "this is a sensitive api, please refrain from using it"
* Existing `pgjdbc` classes like `SingleCertValidatingFactory` (and possibly others) miss `SingleCertValidatingFactory(Properties)` constructor
* It is not clear if `SingleCertValidatingFactory(Properties)` is a much better approach since providing full set of properties might expose properties like login/password
We might introduce annotations for the sensitive apis some time later.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2025-01-23 13:31 "davecramer (@davecramer)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: davecramer (@davecramer) @ 2025-01-23 13:31 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
> * We will not remove it in the nearest future, and `@deprecated` is not the way to convey "this is a sensitive api, please refrain from using it"
Agreed
+1 to un deprecated
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2025-01-23 13:34 "vlsi (@vlsi)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: vlsi (@vlsi) @ 2025-01-23 13:34 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Just to clarify, the PR un-deprecates `SOCKET_FACTORY_ARG` while there's `SSL_FACTORY_ARG` which should be un-deprecated as well.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2025-01-23 13:37 "davecramer (@davecramer)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: davecramer (@davecramer) @ 2025-01-23 13:37 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Same argument is valid. It's not the correct way to express "this is a sensitive api"
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG
@ 2025-01-23 14:12 "sehrope (@sehrope)" <[email protected]>
24 siblings, 0 replies; 26+ messages in thread
From: sehrope (@sehrope) @ 2025-01-23 14:12 UTC (permalink / raw)
To: pgjdbc/pgjdbc <[email protected]>
Yes the title on this PR vs the change don't actually match as the code change itself is for the non-ssl factory.
I'll open a PR to remove the actual sslfactoryarg deprecation.
^ permalink raw reply [nested|flat] 26+ messages in thread
end of thread, other threads:[~2025-01-23 14:12 UTC | newest]
Thread overview: 26+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-06-29 13:17 [pgjdbc/pgjdbc] PR #2923: un-deprecate SSL_FACTORY_ARG "davecramer (@davecramer)" <[email protected]>
2023-06-29 13:29 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 13:30 ` "davecramer (@davecramer)" <[email protected]>
2023-06-29 14:03 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 14:09 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 14:26 ` "sehrope (@sehrope)" <[email protected]>
2023-06-29 14:32 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 14:40 ` "sehrope (@sehrope)" <[email protected]>
2023-06-29 15:02 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 15:17 ` "davecramer (@davecramer)" <[email protected]>
2023-06-29 15:26 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 15:53 ` "jrobe (@jrobe)" <[email protected]>
2023-06-29 16:00 ` "jrobe (@jrobe)" <[email protected]>
2023-06-29 16:18 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 16:26 ` "jrobe (@jrobe)" <[email protected]>
2023-06-29 16:31 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 16:34 ` "jrobe (@jrobe)" <[email protected]>
2023-06-29 16:41 ` "sehrope (@sehrope)" <[email protected]>
2023-06-29 17:02 ` "vlsi (@vlsi)" <[email protected]>
2023-06-29 17:34 ` "jrobe (@jrobe)" <[email protected]>
2023-07-03 14:57 ` "sehrope (@sehrope)" <[email protected]>
2025-01-23 13:24 ` "vlsi (@vlsi)" <[email protected]>
2025-01-23 13:31 ` "davecramer (@davecramer)" <[email protected]>
2025-01-23 13:34 ` "vlsi (@vlsi)" <[email protected]>
2025-01-23 13:37 ` "davecramer (@davecramer)" <[email protected]>
2025-01-23 14:12 ` "sehrope (@sehrope)" <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox