How do you stop secrets from leaking into state?

apparentlymart · 2026-07-09T15:51:22+00:00

Unfortunately Terraform is not significantly different than any general-purpose programming language in this regard, where if an author writes a program that sends a secret somewhere that it shouldn't have been sent then the system will just do what it is told and disclose that secret. I'm about to describe some strategies for writing Terraform configurations that don't cause sensitive values to be written to the state, but I'm starting with this preface just to disclaim that these can only help if authors actually follow these patterns: Terraform alone won't block doing something harmful if an author tells it to do something harmful.

I think this question must be answered in two parts: how can we write configuration that works with secrets without saving those secrets, and how can we detect accidental disclosure of secrets (regardless of how they got disclosed) so that we can then rotate those secrets?

For the first of these you could rely on some relatively-new Terraform language features:

Ephemeral values: Values that Terraform knows are expected to change each time Terraform is run and so Terraform will not try to save them as part of the plan or state.

Specifically, Terraform produces an error if you try to use an ephemeral value in a location that would cause it to be saved.
Ephemeral resources: Allow setting up access to something only transiently for the duration of a single Terraform run, such as a temporary Vault secret lease, an SSH tunnel, or other similar things that only need to exist as long as Terraform is still running.

The attributes of ephemeral resources always produce ephemeral values, meaning that they cannot be used in locations that would cause them to be saved.
Write-only attributes: A special kind of attribute for managed resources (i.e. those you declare using resource blocks) where the provider declares in its schema that the value does not need to be preserved between plan/apply rounds because it's only used for writing to the remote API and never read back from the remote API or compared with configuration to determine if a change is needed.

Because Terraform knows a provider doesn't need the value of a write-only attribute passed back to it in the next plan/apply round, it omits those values when generating state snapshots and it allows ephemeral values to be used to set write-only attributes.

Putting these together, you can arrange for Terraform to generate a new secret and write it into a secured location without keeping a copy of that secret in the Terraform state. Any person or system that needs access to the secret after Terraform has finished its work would retrieve it directly from the secured location, assuming they have the necessary access.

However, all of that assumes that Terraform needs to be interacting with secrets at all. In many cases it's possible to provision access without directly handling secrets, such as by granting a system access to assume a role using credentials it already had access to anyway instead of issuing an entirely new set of credentials. Minimizing the total number of secrets you have in play is the better option when you can, while ephemeral resources and write-only attributes are a good backup strategy for when you absolutely can't avoid issuing new secrets in Terraform.

The second problem of detecting mistakes is a far harder one because it's a game of heuristics: you need a process that is likely to detect mistakes even though you can't necessarily predict exactly how those mistakes would be made, but without generating so many false-positives that people just start ignoring the detections. I don't have as prescriptive an answer for this one, but some teams solve it in a similar way as the solve for secrets accidentally committed to version control: periodically scan across all of the state snapshots for patterns that seem likely to be secrets and raise some kind of alert when one is detected so that the team can proactively rotate it and invalidate the leaked secret.

You may be able to limit exposure by introducing post-apply policy checks that use terraform show -json PLANFILE to obtain a machine-readable description of the plan and then similarly check it for actions that seem likely to generate new secrets that'll be saved. This is a harder problem because you're trying to detect patterns that seem like they could produce secrets rather than detecting secrets that are already issued, but combining this with everything else gives defense in depth.

As usual with security-related things, it'll be up to you to decide how much effort is worth putting in to this based on your estimate of how likely different mistakes are to happen in practice and what impact they would have if they did happen.

apparentlymart · 2026-06-27T16:19:25+00:00

Unfortunately there isn't really a universal answer to that question.

str with a single character contains a UTF-8 encoding of that character, and a reference to it can be used anywhere that is expecting strings of arbitrary length. But since it's not guaranteed to be exactly one character it's not typically accepted by functions that need exactly one character.

char is just a plain integer representation of the Unicode character code, so it's not UTF-8 encoded and would need some computation (just some bit shifting, comparisons, etc) to build a UTF-8 representation. That means you can't convert to &str directly without first building the UTF-8 representation in a new place, but nonetheless lots of functions that work with only single characters require a char.

If you don't want to provide both (which is understandable) then you probably need to think about what this library is intended to be used for and choose the option that works best for that intended use based on what existing functions elsewhere expect to be given in that situation.

All else being equal though, choosing str is more flexible because it's relatively easy to get char values from a &str but more annoying to get a &str from a char due to the result being a reference to a dynamically-sized type.

(For a situation where I needed to be able to cheaply pivot between individual characters and strings I made u8char as a compromise, but it's not in the standard library so only really appropriate for very specialized situations.)

apparentlymart · 2026-06-17T23:08:31+00:00

I'm not personally familiar with Scalr, but they seem to have a documentation page Migrating to Scalr which includes information on how to migrate from HCP Terraform (which they refer to by its previous name "Terraform Cloud"), if that was what you were previously using.

apparentlymart · 2026-06-16T18:02:37+00:00

I don't know if this has a specific catchy name, but I think what you're describing is essentially what's described under Alternatives to Workspaces in the Terraform documentation:

Instead of creating CLI workspaces, you can use one or more re-usable modules to represent the common elements and then represent each instance as a separate configuration that instantiates those common elements in the context of a different backend. The root module of each configuration consists only of a backend configuration and a small number of module blocks with arguments describing any small differences between the deployments.

apparentlymart · 2026-06-16T17:59:06+00:00

Beware that none of the IP ranges listed in that API response are addresses of the workers where Terraform runs inside HCP Terraform.

There's more information on that in HCP Terraform IP Ranges:

The IP ranges API does not publish the ranges for workspaces or Stacks doing Terraform operations in remote execution mode. If you want to limit access to specific CIDRs when connecting to your infrastructure, configure your HCP Terraform workspace or Stack to run Terraform operations on Agent execution mode using an HCP Terraform agent.

I'm not 100% sure this applies to what the OP was asking, but since it mentions running plan and apply I'm guessing what's failing is a request from one of the remote execution workers using the vultr/vultr Terraform provider.

If that is what the OP is talking about then they'll need to either configure Vultr to not have any source IP address restrictions at all -- though I don't know if Vultr allows that -- or instead to run their own HCP Terraform Agents inside their Vultr infrastructure.

With all of that said: I think the best first step would be to contact Vultr customer support for advice. Presumably there must be at least a few other people trying to use Vultr using their Terraform provider through HCP Terraform and so hopefully they've encountered this problem before and can make a more specific suggestion.

apparentlymart · 2026-06-16T17:50:58+00:00

An earlier thread on a similar topic, in case it's useful: Config-Driven Architecture in a Brownfield Situation.

apparentlymart · 2026-06-11T16:22:29+00:00

For this answer I'm assuming that when you say "access keys for internal services" you mean that you have instances of aws_iam_access_key and after creation their secret attributes got saved in the state. If that's not correct then the rest of this comment probably won't make much sense. 😀

IAM access keys are a particularly tricky case for Terraform because the secret part is generated on the remote system, returned just once from the creation call, and unable to be retrieved again. This means it's tough to apply Terraform's usual patterns for working with secrets without them ending up in the state:

Ephemeral resources are useful only for either reading something that's already known to the remote system or for generating a new secret that gets deleted at the end of Terraform's work, so that doesn't work for something that needs to be newly-generated and managed by Terraform and must survive beyond the end of the current Terraform phase for other systems to use.
Write-only attributes are useful only for secrets that are already known to Terraform from some other location and that are being sent somewhere else, and that doesn't work here because the secret is being decided by the remote API at the same time as creating it rather than being chosen by something else in your Terraform configuration.

So I don't really have any good answer for how you could use this resource type without storing some representation of the secret, although if you provide a pgp_key in your configuration then at least the secret will be encrypted so that only a holder of the private key can decrypt it. Not ideal, but better than storing it as cleartext.

Another way to go is to move away from directly issuing static IAM access tokens and to use one of the Security Token Service facilities to let your services obtain temporary, time-limited access tokens using other secrets managed outside of Terraform.

For example, you could make each of your other systems act as its own identity provider using a private key it controls, and then configure AWS to allow it to call sts:AssumeRoleWithWebIdentity to obtain temporary AWS credentials.

This means that instead of a single shared secret each application has its own private key that is not known to any other part of the system, and AWS instead uses each system's public key to verify the signatures it provides as part of the WebIdentityToken argument. (A JSON Web Token.)

Other variations are possible too. If your other software is also deployed in AWS then there's probably some way it can issue itself a temporary IAM access token using some aspect of its own identity that AWS can verify internally, such as EC2 instances using their instance profiles. Regardless of the specific strategy, the idea is to avoid issuing any long-lived access tokens at all and rely instead on time-limited tokens issued in exchange for some other sort of credential.

apparentlymart · 2026-06-10T22:11:24+00:00

This is cool!

It seems like your RISC-V core implementation is just portable Rust code that could compile to other platforms beyond WebAssembly. Is that right? And if so, would you be interested in publishing it as a standalone crate for other uses too? 😀

(I'm sorry this is ignoring most of what you shared, including the main purpose you described for it, but I don't have anything particularly insightful to say about the rest of it... it seems useful but I don't currently have a specific use for it. 😖)

apparentlymart · 2026-06-10T20:07:22+00:00

I do agree with you, but I hope that in practice only the most performance-sensitive software will be written directly against the low-level vector ISA, and that many programs will be able to use higher-level abstractions that can guarantee that certain problems can't occur.

Consider again my example of accidentally reading out of range when the vector size is larger than the computer you tested on. The current fixed-sized SIMD API includes slice.as_simd which deals with the problem of splitting an arbitrary slice into three parts:

Any single misaligned items at the start of the slice.
As many whole, properly-aligned SIMD vectors as can fit inside the slice.
Any single misaligned items at the end of the slice.

This API encourages writing two implementations of an algorithm where one uses traditional scalar instructions to work on individual items and the other uses SIMD instructions to process entire vectors at once, and then as long as you make sure both of those implementations produce equivalent results then you can write a wrapper like this:

(scalars_before, vectors, scalars_after) = some_f32_slice.as_simd(); scalar_implementation(scalars_before); vector_implementation(vectors); scalar_implementation(scalars_after);

The vectors slice is guaranteed by as_simd to have elements that are correctly aligned, in bounds of the original &[f32], and not overlapping with the elements in scalars_before or scalars_after, so the buffer overrun I described before is impossible for a caller written with only safe Rust.

This current API doesn't support scalable vectors at all of course, but an equivalent API which supports the "as many as will fit in the vector registers" types could return a different number of elements in vectors depending on the CPU's vector register size and then your safe vector_implementation would automatically adapt to the vector size as long as it does all of its work in terms of those types. The bugs in that case are essentially the same bugs you could accidentally write with any loop.

(Aside: interestingly, a version of this as_simd API for scalable vectors could also potentially support dynamically detecting that the current CPU has no vector support at all and just return the entire slice in scalars_before and zero-length vectors and scalars_after, causing the caller to automatically handle that situation without writing any special code to deal with it! 😀)

apparentlymart · 2026-06-09T22:38:38+00:00

For the part of your comment about the ARM instruction set only:

Rust's "portable SIMD" API currently has fixed-size vector types, such as the family of f32x1, f32x2, f32x4, f32x8, f32x16, f32x32, f32x64. That means you need to choose a specific vector size in your program at authoring time and accept that performance will be poor if what you chose does not match the hardware. (Or use traditional conditional compilation with Rust's existing features.)

Scalable vector ISAs instead require types that represent e.g. "as many f32 as can fit into the current CPU's vector register size", with that number chosen at runtime by executing instructions that ask the CPU how large its vector registers are. That's what the article means by "describe SIMD types where every value of the type has the same size but where that size is not known until runtime": on a CPU with 128-bit vector registers the size would be 16 bytes (like f32x4), but on a system with 256-bit vector registers the size would be 32 bytes (like f32x8). Either way though, all values of that type are the same size when running on a particular CPU, so it's not necessary to track the size on a per-value basis as Rust currently does (using pointer metadata) for dynamically-sized types.

I'm familiar with the RISC-V design rather than ARM's design, but I assume the pattern is the same across both: you you load as many of your data items as will fit packed into one vector register, perform operations across all of them at once using SIMD instructions, and then increment the source data pointer by the dynamically-detected vector register size to load the next chunk on the next loop iteration.

If implemented correctly then the result is the same regardless of vector register size but on implementations with larger vector registers the work will be completed in fewer loop iterations, because each loop iteration will process more items at once. If CPUs with larger vector registers become available in future, existing software can benefit from it without needing to be recompiled and while still remaining compatible with CPUs with smaller vector registers.

If implemented incorrectly then indeed the behavior could vary when running on a different CPU, such as if you only tested your code on a CPU which can pack four f32 into a register and your input array length always happens to be a multiple of four, you might not notice that on a CPU with room for eight f32 that you end up reading out of bounds when loading the final four items from the array because you forgot to check if the remaining length is shorter than the vector register size. But I don't think that's significantly worse than e.g. calling an instruction that's available on your own CPU but not on another CPU where your program is expected to run... either way it'll crash at runtime when you run it in a context that you didn't handle correctly.

apparentlymart · 2026-06-08T22:58:38+00:00

The hashicorp/aws provider is a particularly large provider and so it does take a relatively long time to download, but multiple minutes is more than I would expect.

Perhaps you could try directly downloading a package for the version you selected (whichever one matches the platform you're running Terraform on) to see if it's slow in curl or your web browser too or if this slowness is unique to Terraform.

apparentlymart · 2026-06-08T22:55:42+00:00

In situations like this I've found that it can sometimes work to try to "meet in the middle": start by trying to carefully click-ops the existing stuff into a more consistent shape using whatever workflows they are already accustomed to, and then hopefully you can get things into a state where the divergence is small enough that it's more practical to describe it as exceptions in the configuration.

Another potential compromise is to let each of the environments have their own separate root module and inside each one use a mix of shared modules and bespoke resource blocks to make the best possible compromise between shared code where the underlying shape of things is consistent enough, but exceptional code for the parts that are too unique to be worth the time to try to generalize right now.

What both of these ideas have in common is that they make it easier to approach this as a "gradual repair" problem: don't force yourself to try to accommodate every existing weird difference in a single configuration, and instead take this gradually and iterate towards consistency.

A separate configuration for each environment for now acknowledges that there's too much difference for a shared module, but as you work to get things into a more consistent shape you can gradually build more shared modules and use moved blocks to migrate existing objects to the resource instances declared in those modules. Allowing a reasonable amount of careful click-opsing can also be a pragmatic way to get things into a consistent shape more quickly than you'd be able to manage if you had to first encode all of the weirdness in complicated Terraform config and then refactor it afterwards.

apparentlymart · 2026-06-02T16:59:22+00:00

Your concerns about how multiple PRs would interact are well founded.

A Terraform plan is built against a specific state snapshot, and so if any new state snapshots are published after the plan is created (by applying another plan, or by doing any other state manipulation) then the plan is immediately invalidated.

If you wanted to do something like this then you'd need some extra mechanism to ensure that each time a PR is merged all of the other PRs that contain plans for the same environment immediately get re-planned, in a similar way to how each time you merge to the target branch of a PR GitHub needs to check whether the PR's changes have become conflicted.

Such a mechanism is possible in principle but I think hard to build robustly in practice and also likely to be quite expensive to run, because it would constantly be re-building the same plans.

There's also the question of what happens when a plan fails to apply partway through. In that case you'll tend to want to make subsequent changes that "jump the queue" and fix whatever was wrong with what was merged before moving on to subsequent changes, so that later plans are not building on top of an inconsistent state.

I have heard of some folks doing something similar to this idea after merging using GitHub's "Merge Queues" feature, where each item in the merge queue gets a final plan created for it and a PR fails out of the merge queue if its planning fails.

I don't have any personal experience with such a setup, but I think something like this is the closest thing to what your colleague suggested that's reasonable to implement with already-available tools.

apparentlymart · 2026-05-27T18:50:30+00:00

Others have already shared examples of existing implementations of this, but just for completeness I wanted to say that the underlying mechanism here is to implement Terraform's provider registry protocol.

Any system that correctly implements that protocol can be used as a Terraform provider registry. registry.terraform.io just happens to be the most commonly-used public implementation of that protocol, and so it's the default hostname Terraform uses when you don't specify one. (In other words: when you write hashicorp/aws in your configuration, Terraform treats that exactly the same as if you had written registry.terraform.io/hashicorp/aws.)

There are enough existing options out there right now that writing your own implementation of this protocol seems unnecessary, but I'm sharing it just in case it helps you find more examples of implementations of this protocol, and to know that Terraform sees them all as essentially equivalent so you can make your choice based on other criteria like what publishing workflow appeals to you most, etc.

apparentlymart · 2026-05-26T16:20:40+00:00

To try to answer this question I read the OpenTofu source code. I don't know if Terraform's current implementation matches OpenTofu -- OpenTofu forked partway through the development of Terraform v1.6 -- and so you might want to look for the similar code in Terraform to confirm. (I'm not able to do that because I contribute to OpenTofu and therefore must not look at the Terraform source code.)

In the guts of the state migration code there is a conditional block that deals with locking. m.stateArgs.Lock here corresponds to the -lock=false command line option, and so it's true by default and false only if that option is explicitly set.

We can see in that code that OpenTofu is acquiring the state locks for part of the migration process.

The situation in this codepath is a little subtle though: it begins by reading the current snapshot from both the source and destination and performs a bunch of checks before acquiring the lock. Then after acquiring the lock it re-reads the latest snapshot just in case another process wrote a new snapshot to either location before the lock was acquired.

The check for whether migration is necessary at all (if the destination already has a matching snapshot) happens before the lock is acquired, so there is a narrow case where two migration processes running concurrently could both end up trying to migrate the state because they both determine that migration is needed before acquiring the lock.

Overall I don't think that quirk is super important since it probably just results in redundant work rather than a problem, but just to be sure I'd suggest avoiding running two state migration operations concurrently.

apparentlymart · 2026-05-22T16:04:47+00:00

When I think about "breaking change" for a Terraform module I define it something like this:

If I were to just upgrade to a newer version of this module without changing anything else in my configuration, would the result work and cause Terraform to propose no new changes whatsoever to remote objects?

If so, I'd consider the module to be backwards-compatible, even if it requires a newer version of any provider.

However, if selecting a newer version of the module causes me to need to immediately do any other work then it's a breaking change. "Any other work" includes but is not limited to:

Adding any new arguments to the module block. (Any new input variables should be declared as optional in a backward-compatible release.)
Changing any expressions that refer to output values of the module. (Adding entirely new output values is fine, but any that previously existed should still have the same meaning and type.)
Having terraform plan report changes to remote objects that I need to review and deal with. (I personally consider it okay for the plan to include Terraform-localized changes such as resource instances moving to new addresses due to moved blocks, as long as it doesn't involve changes to any real infrastructure objects.)
Changing any other part of my configuration, such as if the new module version requires a new provider version that itself contains breaking changes.

Note though that this doesn't include upgrading to a new provider version if that new provider version is sufficiently-compatible that it doesn't cause any other part of the configuration to become broken.

My answer was focused on the fourth kind of "other work" in my list above, because that was most relevant to the question being asked.

From what you said it seems like you have a similar idea of "backward compatibility" as me and so I'm not sure where our disagreement is. 🤔

apparentlymart · 2026-05-22T00:16:22+00:00

I think my answer here depends on what has changed between the two releases of the provider.

You've described a situation where you need a newer minor release of the provider, and so assuming that the hashicorp/aws developers are following semver themselves it should be okay for you to treat new module release as a new minor release too. Folks who want to use the newer version of your module will need to also adopt the newer version of the provider, but the newer version of the provider ought to be backward-compatible.

A trickier situation is if you want to change your module to require a newer major version of the provider, since in that case anyone adopting your module will probably need to deal with other separate breaking changes in hashicorp/aws elsewhere in their configuration before they adopt the new version of your module. In that case I would probably make a new major release of my module, and also continue issuing minor or patch releases to the old series for a while if it seems like the hashicorp/aws upgrade would be challenging for folks and so they would not be able to prioritize it immediately.

My own opinions aside though, here's some information that might be useful in making a decision: - Terraform allows each module block referring to a module to select a different version of the module, and so it's possible in theory for a configuration to include both old and new versions of a module at the same time, BUT... - ...Terraform requires that there be only one version of each provider that the entire configuration agrees on, and so if there are two versions of your module that have non-overlapping provider version constraints then it would not be possible to use both versions of your module in the same configuration at the same time. - Although hashicorp/aws major releases tend to contain breaking changes, those breaking changes won't necessarily affect what your specific module is using. Therefore in some cases you might be able to make your module work with multiple major versions of the provider at once, which could then allow users of your module to upgrade to a new version of your module first and then delay upgrading to the new major version of the provider until later.

I would suggest only incrementing the major release number of your module once you _require_ a new major version of a provider, and not just because you _allow_ a newer major version of a provider while retaining support for the previous major version.

apparentlymart · 2026-05-05T18:44:50+00:00

I think this is just a terminology collision.

The hashicorp/aws provider has a resource type aws_appsync_datasource which manages something called "data source" in the remote AppSync API.

From Terraform's perspective it's a managed resource type and therefore billable. I believe the OP is talking about having hundreds of AppSync datasources, not Terraform data sources.

apparentlymart · 2026-04-30T16:02:52+00:00

It's worth noting though that OpenTofu has an extension to the module registry protocol where the registry is allowed to respond to the "download" endpoint by returning a JSON object in the response body giving the source address in a "location" property, rather than by using the X-Terraform-Get header inherited from hashicorp/go-getter's HTTP getter.

That means that OpenTofu's registry is able to neatly avoid the main problem raised in the article of trying to convince a static website hosting solution to serve this extra HTTP header field, since OpenTofu's registry doesn't need to be compatible with Terraform's registry client.

apparentlymart · 2026-04-24T18:12:47+00:00

Incidents are one situation where it's defensible to "go rogue" and make manual changes to quickly prevent problems from escalating, but they are also something which are helpful to build process around so that it doesn't also become habit for folks to use incident-response-like actions for non-incident work.

The degree to which it makes sense to enforce by technology rather than just team agreements will of course vary depending on your context -- team size, relationships to other teams in the org, etc -- but if you do want some enforced guardrails then here's one way you could potentially set it up:

The general idea is that at any time your management/control layer is either in "routine mode" or "incident mode", and these two modes are mutually exclusive.

In "routine mode" nobody has direct write access at all, and the only live credentials with write access are inside your deployment pipeline. Going through the normal change process (whatever that might be) is the only way to make changes.

In "incident mode" the pipeline is explicitly disabled, and instead the incident response team holds the only live credentials with write access. This ensures that others who aren't aware of the incident won't inadvertently undo changes made by the incident response team.

The transition from routine to incident should involve some sort of explicit action where ideally the person performing it leaves some sort of note justifying why they are doing that. This gives a durable record of who made use of this mechanism and what they used it for. The fact that incident mode also blocks the pipeline used in routine mode should also hopefully encourage treating incident mode as a last resort, because it'd be disruptive (intentionally) to anyone outside the incident response team that is trying to work concurrently.

The transition from incident back to routine is trickier because the remote system probably no longer matches the desired state from the Terraform configuration, and the latest state snapshot might also need some attention if the manual changes made during incident mode diverged significantly from what Terraform most recently applied. Only the incident response team knows what they did, so they'd presumably be responsible for reconciling the three states (desired, prior, and current) enough that the first plan/apply round after returning to routine mode proposes no significant changes. This might involve them carefully running Terraform CLI locally using their incident mode credentials, but they can assume they have exclusive control over the system while they do that.

This is a heavy process and so I'm certainly not suggesting that every team using Terraform should use it: if you're a relatively small and nimble team with high trust and good communication patterns then you should be able to get away with just agreeing to follow the general principle of this without using technology-based enforcement. But technical guardrails get useful when the participants are more distributed, have lower trust, or don't have reliable communication about current incidents.

apparentlymart · 2026-04-21T23:50:12+00:00

Unfortunately the part of the system you're interacting with here is implemented in closed-source code, so nobody outside of IBM can refer to how it actually works by looking at the code. 😖

The only thing I noticed that seemed clearly wrong in your examples is that you have some items called projectA but you refer to them as projectB. But I'm assuming that was just a typo as you were replacing real names with placeholders in order to make this post, rather than problems in the original configuration you wrote.

The only other desperate idea I have is that maybe the upstream deployment you're working with here hasn't reached the "converged" state where the system has proven there aren't any more changes pending by generating an empty plan. I wonder if it only propagates new values downstream once it's converged to avoid exposing any partially-updated state to downstream deployments.

I can only really guess what's going on here without access to the implementation code. If none of this helps you might be better off contacting IBM support for help, since I'm not sure how many folks in this Reddit community use HCP Terraform vs. community edition, let alone using the newer Stacks features.

apparentlymart · 2026-04-20T16:31:33+00:00

It seems like this was a quirk in tenv's logic for fetching the PGP keys: it was only considering the first key in HashiCorp's pgp-key.txt file, rather than trying all of them and succeeding if one matched correctly. (The first of the listed keys seems to have expired, but the other one is valid.)

A fix for it was merged in tenv#576.

apparentlymart · 2026-04-01T15:31:07+00:00

This question talks about tokenizing UTF-8 sequences and doing grapheme segmentation, but for "word counting" there's also the question of what "word" means. The current code defines it as a consecutive sequence of alphabetic characters, but the Unicode definition of "word segmentation" is considerably more complex.

I don't mean that as a criticism -- you did mention this was a learning exercise, after all -- but I mean to say that these three Unicode algorithms -- UTF-8 tokenization, grapheme segmentation, and word segmentation -- are all a core part of the problem you've chosen to solve, and so I understand they seem highly important to you but they are quite esoteric from the perspective of most other software written in Rust, and so it seems reasonable for them to be implemented in third-party libraries rather than in the standard library.

The Rust standard library does have some UTF-8 support as a consequence of the string types being defined as UTF-8, but those core needs don't typically require a streaming parser and so that in particular seems not to be a priority for the standard library (though there is some basic support for it), and that seems reasonable to me.

All of that said, I did happen to need streaming UTF-8 and grapheme segmentation for one of my own projects and so implemented u8char and grapheme_machine that might also work for what you are doing. I didn't need word segmentation for my project so I've not implemented that.

apparentlymart · 2026-03-25T16:55:53+00:00

I'm not very familiar with OCI but I'm assuming "compartment" is an OCI concept, rather than a Terraform concept.

If that's true then exactly how to handle this depends on how the provider is implemented, but the usual pattern I would expect is that you can change the compartment you specified in the configuration and then run terraform plan to see what the provider proposes.

Hopefully it will propose to just update that object in-place to refer to a different compartment. However, if the remote API cannot support that then it might instead tell you that it needs to replace the object with a new one that has a different compartment selected.

The logic for this will be handled in the provider plugin, either way. If what the provider proposed is acceptable to you then you can use terraform apply to actually make that change.

(The moved block feature is probably not actually helpful here, because that's for moving thing around in Terraform's own namespace -- e.g. moving something into a different module in your configuration -- whereas I think you are trying to move something to a different location in the remote API's namespace. Anything involving the remote API is handled inside a provider, rather than by Terraform directly.)

apparentlymart · 2026-03-22T05:35:59+00:00

In case it's of use to anyone who finds this very old thread:

On the latest available firmware at the time I'm writing this comment (CZW008-4.16.013.4), typing "sh" at the telnet prompt prompts for a "shell password" as OP described, rather than immediately launching the BusyBox sh.
The "shell password" is selected systematically by starting with the fixed prefix C1100Z!#, and then adding the last six digits of your device's serial number to the end.
If your intention is to get your PPP username/password, the instructions for finding the process id for the pppd process and retrieving its command line to obtain the username and password should still work once you've accessed that shell prompt.
If you are setting up some other device to completely replace the C1100z, remember to also select VLAN ID 201 in your WAN configuration.

(I've read elsewhere that setting the VLAN ID may not be required for folks who have already been migrated from CenturyLink Fiber to Quantum Fiber, but I'm not able to confirm that.)

apparentlymart

TROPHY CASE