Add the Fee-1.0 schema in production, allowing the requests with this
extension to be parsed. This allows us to test this extension before hand.
The announcement of this extension in greeting is controlled by a
feature flag in ProtocolDefinition.java. As long as it is not announced,
we do not expect real customers to use this extension.
I think this may have been introduced as part of Gradle 9? Not sure why
it's not showing up in the remote builds but without this, I can't run
any "devTool" commands.
Note: the fixes were suggested by gemini-cli
Our existing precision is milliseconds so we want to stick with that for
Instants. If we want to increase the precision globally after that we can do so
all in one go post-migration, but for now, it would be a bad thing to have mixed
precision going on just depending on whether a class happens to be migrated yet
or not.
This PR also migrates all existing DateTime.nowUtc() calls to use the Clock
interface, so that when they are migrated they will get the benefit of this
precision-setting as well.
BUG= http://b/496985355
Error-prone introduced many more checks in Java 25. We fixed a few
and suppressed most. A follow-up bug is opened to clean this up.
An ai agent should be able to clean up most of it.
This PR is created with gemini-cli. Summary of experience:
* The good: AI caught most compatibility issues, and with permission,
suppressed them through compiler flags and errorprone options.
It also caught many versio references in scripts.
* Where it didn't shine:
- It did not find and update the target version spec in the custome
VKey annotation processor source file.
- It did not flag eclipse-temurin:21 docker image for upgrade.
- When running into failure, its first instinct is to disable checks
e.g., -Werror instead of fixing them.
We don't need these, so there's no point in adding database load (but we
leave the option to include them in the future). Note that these are,
and were, only ever included for domains so we don't need to worry about
hosts.
java.time has been around since Java 8 and was based on joda DateTime, so this
is an overdue migration. We're migrating specifically to Instant in most places
rather than ZonedDateTime because we were always using DateTimes in UTC to
reference a specific instant, which is exactly what Instants are
for. ZonedDateTime set to UTC may still be useful in some places that are heavy
on date math (especially in tests).
There is a lot more work to be done after this, but I wanted to put together a
manual PR showing my overall approach for how to do the migration that I can
then hopefully follow along with AI to continue making these changes throughout
the codebase. The basic approach is to migrate a small number of methods at a
time, marking the old methods as @Deprecated when possible (not always possible
because of @InlineMe restrictions). This PR doesn't yet migrate any DateTime
fields in the model classes, so that's the one remaining type of refactor to
figure out after this. We won't be changing how any of the data is actually
stored in the database.
BUG= http://b/496985355
Previously we would just use the first one we found. This is a valid
behavior, but we want to change it so that we apply the cheapest default
if multiple are available (this way we avoid having to go back after the
fact and give refunds).
* More Gradle 9 preparations
Fix additional compatibility warnings after upgrading to Gradle 8.14.3
from 8.13.
* More Gradle 9 compatibility fix
More fixes after upgrading Gradle from 8.13 to 8.14.3.
Upgraded the gradle-license-report plugin, and handled config leaking
issues.
Researched using gemini web and manually applied the fixes. Gemini-cli
could not find the right solution.
This ended up being wayyyy more complicated than expected due to
issues with Hibernate, various dependencies having conflicts with the
proto dependency version, and other breaking changes.
Notes:
- Hibernate 7 switches up the user type / converter system and for us,
this means we must be / want to be more explicit with how we convert
and store things. For example, we need to add Postgres types to @Column
definitions.
- Hibernate 7.3 has an issue with generic MappedSuperclasses -- we have
issues with BaseDomainLabelList. I'll investigate that, but for now
let's stick with 7.2.x
- H7 is more strict with annotations and prevents us from storing mapped
superclasses embedded within other objects. This kinda makes sense but
makes the History objects a bit more difficult. We had to add "concrete"
embeddable DomainBase and HostBase objects that we can store/retrieve
from the DB.
- We convert some of the calls to "Query" to "TypedQuery" -- in
Hibernate 8 / JPA 4.0 these will be super-deprecated and we'll need to
shift everything over, so this is necessary.
- You aren't supposed to put callback listeners on embedded entities
(because it can be not obvious what's happening). We don't like that,
so we add our own annotations that are processed recursively for
embedded entities, so we get things like the update / create
timestamps.
- Hibernate doesn't allow for multiple converters to be auto-applied to
the same "type" and it counts all VKey converters as one type.
Unfortunately, this means we have to explicitly mark each one.
- A bunch of other dependency changes were required to keep from having
the proto 3/4 conflict
Previously we omit the fee class in responses if the class is standard.
After a rereading of Section 3.7 of RFC 8748, we determined that the fee
class element should be included in all cases.
Note: the `collison` class now becomes `standard-collision`.
Refactor Gradle scripts to replace usages incompatible with Gradle 9.
PR prepared mostly with gemini-cli, with one issue (project.exec)
researched with gemini web and manually applied.
The actual upgrade to Gradle 9 will be in another PR.
Verified: none of the issues reported in build/reports/problems/problems-report.html
is related to Gradle 9.
PR 2917 added two `get(tld)` methods to ClaimsListDao and
SignedMarkRevocationList so that RST test TLDs can have separate claims
and smdr lists.
RST tests are completed and this functionality is no longer needed. we
are replaceing all invocations of the above to `get()`.
The JDK version of SSL has long supported TLS v1.3 (since version 11) so
fortunately we can use TLS v1.3 regardless if which implementation of
SSL we're using.
We prefer OpenSSL in general so I'm not entirely sure why we were using
the JDK version of SSL on the proxy before, but this should work and be
a good idea regardless.
Tested on alpha by running
```
$ openssl s_client -connect epp.registryalpha.foo:700 -tls1_3 -ciphersuites "TLS_AES_128_GCM_SHA256"
```
Previously we'd get a failure, now it returns the proper cert data.
We should be at least at a "good enough" state after this -- I'm sure
there are many updates we could make that would improve the
documentation but this is definitely much improved from before and
should hopefully be good enough to get people started.
This doesn't update everything -- it leaves out some of the more
complicated changes (architecture, code-structure, configuration,
install, and proxy-setup). Those will require more complete rewrites, so
I'm punting them to a future PR.
The only type of thing that can be transferred now is a domain, so
there's no point in having this abstract class / redirection.
This does not include deletion of the contact-response-related XML
classes; that can come next.
This doesn't remove everything -- there are still other contact-related
objects that we'll need to remove (e.g.
ContactPendingActionNotificationResponse) and simplifications we'll need to make
(e.g. only domains can be transferred now, so all transfer data can move
there instead of being generic)
But this removes the bulk of the remaining contact-related code. We'll
keep around the XML request objects, since it's still nice to route them
to the appropriate (exception-throwing but logging) flow class.
For all flows that use Fee extensions, normalize the fee tags in all
non-prod environments.
For flows that do not use fee extensions but with fee tags in the
header, e.g., HostInfo flows, normalization is not performed.
This avoids changing any functionality, including the bits of
DomainCommand (representations of XML files) that reference contacts.
Currently, we "allow" parsing of contacts in DomainCommands and fail
later as part of the domain flow, even though in practice the parsing itself will fail now that no
contacts exist in the database.
Because we wish to keep the "contacts aren't allowed in flows" tests
active (e.g.
DomainUpdateFlowTest::testFailure_minimumDataset_whenAddingNewContacts)
we have to keep the usages of contacts in DomainCommand active for now.
We have a restriction in our system that registrar display names be unique (as
the display name is how registrars are queried through RDAP). And, the
uniqueness constraint is enforced on the canonicalized version of the display
name (with spaces and non alphanumeric characters removed). However, in the
check enforcing this uniqueness, we were incorrectly checking against the
existing saved entity of the same registrar, meaning that you couldn't update
the display name of a single registrar to a new value that canonicalized the
same (you would instead have to rename it to something else first that doesn't
canonicalize the same, and then afterwards to the new desired value).
That didn't make sense, so now we exclude the existing registrar entity from
consideration when checking if there are conflicts.
The current SQL credential store was designed to support automatic
password rotation without any disruption to the applications. For that
goal, the credentials are stored with one level of indirection, and the
secret name of the actual credential data may change automatically.
The automatic password rotation feature has been dropped. In the
meantime, the need arises that we use sidecar SQL proxy to get around
the Enterprise Plus edition's post-maintenance reconnection failures
by the socket factory library. This is hampered by the indirection in
storage.
This PR removes the indirection. This change is transparent to the rest
of the code base. We will manually populate the secret manager with the
new secrets in all environments after submissiion of this PR.
* Normalize Fee extension XML tags in EPP response
Nomulus currently supports multiple versions of the Fee extensions. Our
current tooling requires that each version must use a unique namespace
tag, e.g., fee11, fee12, etc.
Some client registrars are sensitive to the tag literal used by the
version of the extension they use. For example, a few registrars
currently using v0.6 have requested that the `fee` literal be used
on the versions they currently use. With registrars upgrading at their
own schedule, this kind of requests are impossible to satisfy.
This PR instroduces a namespace normalizer class for EPP responses. The
key optimization is that each EPP response never mixes multiple versions
of a service extension. Therefore we can define a canonical tag for each
extension, and change the tag of the extension in use in a response to
that. This normalizer only handles Fee extensions right now, but the
idea can be extended to others if use cases come up.
This normalizer will be applied to all flows in a future PR.
* Addressing reviews
* A faster implementation with regex.
b/478848482
This primarily affects the EPP greeting. We already were erroring out when any
contact flows attempted to be run; this should just prevent registrars from even
trying them at all.
This PR is designed to be minimally invasive, and does not remove any of the
contact flows or Jakarta XML/XJC objects/files themselves. That can be done
later as a follow-up.
Also note that the contact namespace urn:ietf:params:xml:ns:contact-1.0 is still
present for now in RDE exports, but I'll remove that subsequently as well.
This is a redo of PR #2932, which had been reverted, but now controlled via
FeatureFlag so that it won't be enabled until we schedule it to do so (and only
after sufficient time has passed after notifying registrars in advance).
BUG= http://b/475506288
We've moved on from contacts entirely now so the only thing we really
need to do is make sure that people don't include contacts in domain
creates or updates. This also makes auth code checking easier too,
because now the only auth code that you're allowed to provide is the
domain auth code (not a contact auth code)
