Talk:Protecting Memory Secrets: Difference between revisions

Line 71:

::First, what is a secret? Is it a bit pattern or is it the information represented by that bit pattern? (A bit pattern is much easier to deal with, in a concrete sense, than an abstraction is.)

::: Several examples of secrets are given in the description. For the example any set of characters or numbers will do. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

::Second, what does it mean to erase a secret? Specifically: how much responsibility must the software author have over the underlying hardware and operating system? (For example: if the operating system has swap enabled, or preserves memory images in some other fashion, is that an issue for the language or is that out of scope for this task?)

:::: I explained the language of the standard and further elaborated the intent was to minimize the time a secret is vulnerable to memory skimming. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

::Third is there some meaningful "minimum size" for consideration here? Short bit patterns can happen coincidentally so are probably not relevant, correct?

:::: This is getting pedantic. The size of the secret is not relevant to the task as defined. Only the capability is. If you like call it a credit card. There are several well known 16 digit test cards 4111....1111, 42...42, 54..54, but it could be anything and at least one of the contributors made up their own. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

:Philosophically speaking, all secret knowledge is temporary -- either all holders of the secret expire, losing the knowledge, or the information is eventually propagated or re-discovered rendering it non-secret. Here, we're aiming for partial expiration -- partial because of limitations of software scope. But we still need to define that scope.

:::: Philosophy? Really! There is a defined objective. If you disagree with the philosophy behind the standard either challenge it or avoid it. That doesn't make this an invalid task. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

:Anyways... it seems to me that adequately addressing this task takes us deep into rosettacode's "[[Rosetta_Code:Add_a_Task#Things_to_avoid|things to avoid]]" territory. --[[User:Rdm|Rdm]] ([[User talk:Rdm|talk]]) 05:28, 15 January 2023 (UTC)

:: Really which ones? I am not asking for a specific language feature. I am asking people who use various languages to provide guidance on how they would meet the intent of a requirement. I'm not even asking for an exceedingly rare feature. I'm not looking for an extremely small solution - I've gone out of my way to be flexible and solicit the input of folks that know their languages. And I have not asked for the fastest possible solution. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

: I will reiterate, I made this a draft task for the reason that it isn't as well defined and may change or evolve. I expect this will be evolution toward more clarity as solutions appear. Folks responding to draft tasks know that. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)

: I get that for whatever reason, this task seems to offend your notion of RosettaCodeness, but your arguments aren't convincing. Just because it isn't a neat and tidy little algorithm doesn't invalidate it. Please feel free to '''ignore''' this task if you don't like it. [[User:EnigmaticC|EnigmaticC]] ([[User talk:EnigmaticC|talk]]) 23:32, 15 January 2023 (UTC)