WEBVTT

00:00.000 --> 00:16.440
All right, then, let's continue concluding this cheesy

00:16.440 --> 00:24.360
segmental step room at first term 2026 with the final presentation today.

00:24.360 --> 00:30.440
Pairic Philippe also has made a decision in life, different one than Jose and his decision

00:30.440 --> 00:37.040
was to come back every two years with GCC analyzer related presentation.

00:37.040 --> 00:41.040
So yeah, this one is about the proposal of a secret attribute.

00:54.360 --> 01:22.360
So I'm here to present an ongoing work on the definition of a set of attributes for a secret

01:22.360 --> 01:23.840
within GCC.

01:23.840 --> 01:28.200
And more specifically within the analyzer for now.

01:28.200 --> 01:35.040
So for those few who doesn't know, so in 2020, there was a stage analyzer introduced in

01:35.040 --> 01:43.520
GCC, and so it doesn't operate on a gimbal, so actually quite just at the late stages

01:43.520 --> 01:46.480
of the middle end, actually.

01:46.480 --> 01:49.440
So it does leverage an optimization dependent analysis.

01:49.480 --> 01:53.640
So of course, it's only on the middle end, so all the analysis on the back end are

01:53.640 --> 01:57.720
not seen by the analyzer, of course.

01:57.720 --> 02:04.760
And so it is quite nice frame, actually, for a section to relate to the analysis, so far

02:04.760 --> 02:12.560
it does mostly have memory related analysis.

02:12.560 --> 02:18.560
So for example, the analyzer is able to detect an open to the reference in the procedural

02:18.640 --> 02:19.560
context.

02:19.560 --> 02:26.280
So here, for example, you have a dummy program with a lasing and here, in the food

02:26.280 --> 02:31.480
function, you have the null points or the reference happening.

02:31.480 --> 02:37.160
And here in the terminal, you can see that the analyzer is able to have quite nice diagnostic,

02:37.160 --> 02:45.120
quite easy to understand, thanks to David Malcolm work, as I don't think he's here.

02:45.200 --> 02:50.640
So you can see that there's a number and ordered event, and so it's quite easy to understand

02:50.640 --> 02:59.840
at a different pass, leading to the issue.

02:59.840 --> 03:08.840
But unfortunately, there are other kinds of issues than memory related issues in C-program.

03:08.840 --> 03:13.760
One of them are related with secrets, and here, for example, you have, so it's a quite

03:13.760 --> 03:20.400
unique technique and vulnerable authentication, so you can see that the developer here

03:20.400 --> 03:28.520
is allocating space for a password, then get the password from the user, it validates

03:28.520 --> 03:34.480
it against an expected password, which is here, are coded, for example, so you should

03:34.480 --> 03:37.200
never do that, obviously.

03:37.200 --> 03:42.200
And depending of the validation, well, the program returns a result.

03:42.200 --> 03:48.400
And for some reason, the developer here decided to say, well, how the validation failed.

03:48.400 --> 03:55.160
So I was expecting actually the full-marked password, so we ran me again and then we're

03:55.160 --> 03:56.160
good.

03:56.160 --> 03:58.960
So obviously, you shouldn't have a do-that's.

03:58.960 --> 04:05.960
And actually, well, this is not detected by the compiler or by the GSA's.

04:05.960 --> 04:11.920
And so this first of all, because, well, this is not possible, and it's due to a semantic

04:11.920 --> 04:17.520
gap, actually, between programming languages, I don't know if it's possible in Algorithm

04:17.520 --> 04:22.280
or in Algorithm's, and secret leakage, actually.

04:22.280 --> 04:25.200
And so we focused on C here.

04:25.200 --> 04:31.880
And so usually, we describe our programs with two, this joint set of properties.

04:31.880 --> 04:34.840
So on one hand, you'll have the functional properties.

04:34.840 --> 04:38.760
So basically, what your program should do, or not do.

04:38.760 --> 04:41.800
So for example, your program should not crash.

04:41.800 --> 04:48.640
And the other set is the set of the non-functional properties, which are basically describing

04:48.640 --> 04:49.640
everything else.

04:49.640 --> 04:56.000
So for example, is your program doing what it is doing in a safe way, or in a secure way,

04:56.000 --> 04:58.640
regarding this or this model.

04:58.640 --> 05:04.960
And actually, memory-related issues, such as the no-point of the reference, for example,

05:04.960 --> 05:08.360
well, that's a violation of a functional property.

05:08.360 --> 05:13.160
But printing a password is a violation of a non-functional property.

05:13.160 --> 05:17.880
And so that is outside of the compiler, actually.

05:17.880 --> 05:22.120
And so this is because mainly C, for example, has no concept of secret variable that's

05:23.040 --> 05:24.200
all.

05:24.200 --> 05:33.840
And so there has been a lot of tools and work to target secret-related issues.

05:33.840 --> 05:39.880
But usually, they are tied to specific vulnerability, or a set of specific ones.

05:39.880 --> 05:44.680
And usually, they are tools outside of the compiler.

05:44.680 --> 05:49.080
But according to some surveys, here you have both work from academic and industrial

05:49.080 --> 05:52.280
word.

05:52.280 --> 06:00.040
So there are actually two problems coming out from a lot of tools.

06:00.040 --> 06:05.800
One of them is that some tools require developers to break their blocks, and so, well, if

06:05.800 --> 06:12.400
you need to use a tool that will break your habits, well, you probably won't use it.

06:12.400 --> 06:15.440
And the other thing is the diagnostic itself.

06:15.480 --> 06:21.320
So if a tool has a complex or a noisy diagnostic, well, you probably won't lose time

06:21.320 --> 06:24.320
trying to understand it.

06:24.320 --> 06:27.000
And actually, those are usuality issues.

06:27.000 --> 06:34.680
And so, we think about it, and we thought, well, actually, this is already part of

06:34.680 --> 06:37.080
a lot of developers work flow.

06:37.080 --> 06:43.960
And also, well, the GSA already implemented quite a nice reporting system, as we've seen.

06:43.960 --> 06:51.800
It is also trying to go for a soundly analysis, so that means, try to aim for soundliness.

06:51.800 --> 07:00.280
So that means, as sound as possible.

07:00.280 --> 07:07.960
And so, we asked ourselves, well, could we detect secret dependent data being passed to a

07:07.960 --> 07:10.440
leaking function within the GSA?

07:10.440 --> 07:15.920
So here, secret dependent data means that sometimes in your program, well, your secrets.

07:15.920 --> 07:20.640
So, for example, the password or cryptograph keys, well, they might propagate it to other

07:20.640 --> 07:23.600
variables during your program's execution.

07:23.600 --> 07:29.480
So here, for example, you have the secret variable, which is secret by definition, and the

07:29.480 --> 07:33.320
X variable, which is initialized, depending of that secret.

07:33.320 --> 07:36.640
And here, X is depending on the secret.

07:36.640 --> 07:40.000
So it is secret dependent.

07:40.000 --> 07:48.680
So we tried to think of a set of attributes to identify and mimic the behavior of the

07:48.680 --> 07:51.680
secrets in the program.

07:51.680 --> 07:58.800
And so, at the first stages of our thoughts, we were actually returning on something which

07:58.800 --> 08:01.120
is close to the binary model.

08:01.120 --> 08:07.040
So we are still thinking about memories and registers, but actually we are in the compiler.

08:07.040 --> 08:12.960
So we were thinking, well, maybe we could resume on the programming language itself.

08:12.960 --> 08:17.600
Because it has several more advantages, because, for example, programming language, well,

08:17.600 --> 08:23.000
they have meets our information on variables, for example, such as Swiss fires, but also

08:23.000 --> 08:26.880
it was cooked and a type.

08:26.880 --> 08:29.120
Whether in binary, well, a variable doesn't exist.

08:29.120 --> 08:32.800
There is only the registers and addresses.

08:32.800 --> 08:38.240
But it can also work for the concept of function, because in C, for example, well, your

08:38.240 --> 08:44.480
function, they might be defined or on it declared, and they have, or not, they may or

08:44.480 --> 08:48.920
not have inputs, so for example, parameters in C.

08:48.920 --> 08:54.160
But they also may have one or several outputs, such as a written value, but they could

08:54.160 --> 09:00.560
also write to one or several of their parameters.

09:00.560 --> 09:04.160
And this doesn't exist in binary, also.

09:04.160 --> 09:10.280
And so we tried to think about the different ways to create secret in C.

09:10.280 --> 09:21.680
And so we came out with four different ways, so the first one is actually quite easy to understand.

09:21.680 --> 09:22.880
It's a local variable.

09:22.880 --> 09:27.080
You have a local variable with an inflection, and you know it is secret, because for example,

09:27.080 --> 09:30.960
is a password.

09:30.960 --> 09:32.840
But there is also the notion of type.

09:32.840 --> 09:38.200
A type might always, by definition, be secret, such as in every case, for example,

09:38.200 --> 09:41.800
the private key will always be private.

09:41.800 --> 09:46.600
And you have also two other cases, which are the fact that some function, you know that

09:46.600 --> 09:51.280
one of the parameters will always be secret when you call it.

09:51.280 --> 09:56.280
So for example, an encryption key of an encryption function.

09:56.280 --> 10:00.840
So in that case, that means that when you enter that function, you should always consider

10:00.840 --> 10:04.440
that parameter as being secret.

10:04.440 --> 10:11.560
And another case is more type to secret generation function.

10:11.560 --> 10:17.360
In those case, for example, when you're generating random, you might want to check that

10:17.360 --> 10:19.400
you are not returning zero.

10:19.400 --> 10:26.280
But in fact, checking your secret against another value is actually leaking information.

10:26.280 --> 10:30.840
It's a constant time vulnerability, bailation.

10:30.840 --> 10:36.120
And so in that specific case, you might say, OK, so I know that this will be a secret,

10:36.120 --> 10:40.080
but only at the end of my function execution.

10:40.080 --> 10:45.640
And so we designed three field sensitive attributes to identify secret.

10:45.640 --> 10:48.160
So the first one is the secret attributes.

10:48.160 --> 10:53.960
So it can be tied to variables or parameters, but only to define functions.

10:53.960 --> 11:00.240
And so in that case, that we mean that the decorated parameters will be considered secret

11:00.240 --> 11:01.440
from the function entry.

11:01.440 --> 11:09.360
So for example, the encryption function, previously, that I shown previously.

11:09.360 --> 11:14.160
There is the secret attributes, which can be tied to parameters or written value.

11:14.160 --> 11:18.040
So here, it can be applied on defined or in defined functions.

11:18.040 --> 11:22.800
So for example, it can be applied on headers, for example.

11:22.800 --> 11:25.440
And the secret type, of course.

11:25.440 --> 11:29.880
So this means that it can be used on type definitions, for example.

11:29.880 --> 11:36.040
And in that case, it means that each instances of that type will be considered secret

11:36.040 --> 11:42.000
at declaration.

11:42.000 --> 11:49.800
But so OK, we can identify secret, but that's not enough because, well, there are some

11:49.800 --> 11:55.600
function that have side effects regarding secrets, such as memory copy, for example.

11:55.600 --> 12:00.520
So if you take a password and you copy it somewhere, well, the destination of that memory

12:00.520 --> 12:03.520
copy should become secret too.

12:03.520 --> 12:09.000
But there are also some distracting functions, such as B0, for example, which we know will

12:09.000 --> 12:12.680
result in the secret being destroyed.

12:12.680 --> 12:20.440
And since we want to detect some linking function, we also call them the answer function.

12:20.440 --> 12:24.960
So those are the functions that should never be used with secret, because we know that

12:24.960 --> 12:28.720
they link information about them.

12:28.720 --> 12:32.800
And actually, those function, we don't need to have access to their definition.

12:32.800 --> 12:37.160
We only need a way to be able to identify them.

12:37.160 --> 12:44.000
But one way way would be to say, well, we just have to manage a use database with all

12:44.000 --> 12:45.000
the functions.

12:45.000 --> 12:49.960
Well, actually, it's quite impossible, of course, because you can have project specific

12:49.960 --> 12:56.080
functions, such as project specific memory copy or even distracting functions.

12:56.080 --> 13:01.320
But also, some linking function might be conceptive dependence, because in some cases, for

13:01.320 --> 13:08.160
example, the length of a buffer should be considered as secret, but not in other cases.

13:08.160 --> 13:11.000
And so we designed three function attributes.

13:11.000 --> 13:16.520
So the propagator attribute, which in this case would say, okay, so the source, if it is

13:16.520 --> 13:23.280
stented, it is secret, then the destination will become secret.

13:23.280 --> 13:26.720
The structure attributes and the unsafe attributes.

13:26.720 --> 13:34.600
And so we implemented this attribute system alongside Tane's propagation mechanism within

13:34.600 --> 13:38.320
the GSA, so within a state machine.

13:38.320 --> 13:40.320
And we called it Gnosecrit.

13:40.320 --> 13:47.320
And so, thanks to Gnosecrit, we are currently able to detect this dummy program as being

13:47.320 --> 13:50.240
a real normal here.

13:50.240 --> 13:57.240
And so this is an ongoing work, and so to conclude this talk, I would say that we are trying

13:57.240 --> 14:02.880
to leverage a secret analysis within Gnosecrit through a set of attributes.

14:02.880 --> 14:08.520
So this is interesting, because attributes can be safely ignored by compilers, so that

14:08.520 --> 14:20.200
means that Gnosecrit, so that means that some projects could use Gnosecrit related, vulnerability.

14:20.200 --> 14:27.640
So I will still be able to compile with, for example, or CLAN.

14:27.640 --> 14:32.080
And so currently we are still working on the evaluation of Gnosecrit, so namely the false

14:32.080 --> 14:34.720
positive and negative rates.

14:34.720 --> 14:41.240
And our current approach is to use a tool to generate random C programs, such as YRGEN,

14:41.240 --> 14:47.080
for example, to use data flow analysis to find different dependencies between variables, and

14:47.080 --> 14:56.520
to annotate the code in a, but the magic way to then run our tool, and yeah.

14:56.520 --> 15:03.520
So the idea of this talk was to be able to have a return from the community, maybe, so

15:03.520 --> 15:13.960
you said that if that was you think it was, it's not okay, to have feedback actually.

15:13.960 --> 15:22.880
And even if you have any experiences with generating random C programs and annotating

15:22.880 --> 15:30.640
it in automatic way, well, please, I would love to have anything.

15:30.640 --> 15:32.920
And so feel free to reach out.

15:32.920 --> 15:39.720
There is a link to my website, so it's definitely not updated yet, but yeah, thank you.

15:39.720 --> 15:56.520
I'm here to ask you, do you plan to expand the impact of those attributes out of this

15:56.520 --> 15:59.000
that I can analyze her?

15:59.000 --> 16:04.040
For example, if some variable is secret, you will have a little bit memory, you can kind of avoid

16:04.040 --> 16:05.040
that.

16:05.040 --> 16:12.800
Okay, and that's one, so that's one, because also the functionality and not functionality

16:12.800 --> 16:16.080
goes, I'm thinking about verifyability.

16:16.080 --> 16:20.720
So I would love to see other attributes for all the non-functional processes impacting the

16:20.720 --> 16:24.400
behavior of this mutation process, do you plan to go there?

16:24.400 --> 16:30.280
Okay, so the question is regarding the attribute themselves, or they're tied to the

16:30.360 --> 16:34.000
static analyzer themselves, itself, or outside of it.

16:34.000 --> 16:43.320
And also do we plan to extend them to, so for example, an optimization passes.

16:43.320 --> 16:50.320
So the first question is the answer is yes, it kind of is outside, because it's actually

16:50.320 --> 16:57.880
plug-in, so thanks to I don't remember the, but you can define attribute by plug-in.

16:57.880 --> 17:03.720
And so far it's only a plug-in to test our ideas.

17:03.720 --> 17:09.080
And yeah, we would like to go there to, to go to make some optimization passes, such

17:09.080 --> 17:15.320
as that search validation, for example, aware of, so those data are secret, so we should

17:15.320 --> 17:19.680
not, for example, deal it, call to a man's set, or something like that.

17:19.680 --> 17:27.240
There was one question on the line, maybe we should take that to give them a chance.

17:27.240 --> 17:28.240
Yeah.

17:28.240 --> 17:33.200
How much of this C-C-Prid property is based on Perl's Tainter concept?

17:33.200 --> 17:42.480
Okay, so the question is regarding, so the Tainter propagation, I think, and the fact

17:42.480 --> 17:50.240
that there is an implementation, which in Perl, I think, so it goes back in, I don't remember,

17:50.240 --> 17:52.360
but it was in the 90s, I think.

17:52.360 --> 18:00.920
So to, in Perl, I think it was to analyze secret, but mostly password and things like that,

18:00.920 --> 18:05.840
as far as I know, and it's pretty much a similar idea, actually.

18:05.840 --> 18:11.720
The idea is to push it on, on the compiler, such as just a C, for example.

18:11.720 --> 18:18.080
And so we focused on C because there is actually a lot of cryptographic code developed

18:18.080 --> 18:25.120
in C so far, and so the idea was to go for C first and then see if we could go, well, to

18:25.120 --> 18:33.560
grow the language, to, I mean, to, why didn't the different target languages?

18:33.560 --> 18:34.560
Yeah.

18:34.560 --> 18:35.560
Okay.

18:35.560 --> 18:36.560
Okay.

18:36.560 --> 18:55.920
Okay, so the question is regarding the condition of propagators on the custom memory, for

18:55.920 --> 18:56.920
example here.

18:56.920 --> 19:03.920
So here that means that this nation, after the evaluation of the call to the custom

19:03.920 --> 19:12.240
copy function, the destination parameter, so the argument at the call site, will be considered

19:12.240 --> 19:16.240
secret if and only if the parameter here is secret.

19:16.240 --> 19:28.400
Yeah, but thanks to the analyzer, the source could, for example, not be fully tainted, so

19:28.400 --> 19:33.600
not fully be secret, but the analyzer is aware, thanks to some

19:34.600 --> 19:41.600
it's true, it's memory model, it's able to only propagate, for example, some pieces of an array

19:41.600 --> 19:51.200
or of another integer, if it's regarding the type, I mean, we haven't pushed that far,

19:51.200 --> 19:55.520
the test we're going to type attribute yet, but that would be interesting to see if the analyzer

19:55.520 --> 20:01.760
attribute, I think it can, I think that is Malcolm worked on that, yeah, yeah, the secret

20:01.760 --> 20:10.320
attribute for the array, yes, related to the mindset that there is a normal version of

20:10.320 --> 20:19.520
mindset that is, yeah, mindset S, for example, yeah, I don't know, there's enough, a new

20:19.760 --> 20:26.480
version of mindset that was added to the C23, to enforce the website even if it lives

20:26.480 --> 20:33.440
useless, okay, so anything containing a separate must be clear before you answer the function,

20:33.440 --> 20:43.360
yeah, yeah, yeah, so actually this work is based on

20:43.360 --> 20:52.480
traduce work where we were detecting missing the realization, especially of secret, yeah,

20:58.480 --> 21:06.400
oh, no, no, this is C23 standards, actually, yeah, this is C23 standards, to also the question

21:06.400 --> 21:20.240
was regarding this annotation, but what were they thinking about, yeah, so it's C23 standard that

21:20.240 --> 21:31.440
pushed some standard, yeah, but I mean, so far we are still using the old, this was just to fit

21:31.440 --> 21:45.840
in the presentation, so far we are actually not C23 compile, well, compiling, yeah, yeah, so how

21:45.840 --> 21:52.720
exactly are you getting the compiler in the course in constant type guarantees? Oh, we're not,

21:54.320 --> 21:59.440
so the question was regarding how do we enforce the compiler to respect

22:00.160 --> 22:05.600
a constant time guarantees, so we're not, because actually the analyzer so far is only,

22:08.640 --> 22:17.280
it kind of is a huge abstraction of the DCC itself, I mean, it's easier to go

22:18.000 --> 22:25.200
within the analyzer than to start digging into the whole compilation pipeline of DC,

22:26.000 --> 22:33.520
and so the idea was to play around first, be able to see if we were able to detect some problem

22:34.400 --> 22:41.120
and the idea behind the propagation, well, the attribute is to make them available to the whole

22:41.120 --> 22:49.120
compilation pipeline, and maybe if we are able to detect it in the analyzer, then we should be able

22:49.120 --> 22:55.840
to make it, well, to make, for example, the necessary nation pass, aware of that, but also some

22:55.840 --> 23:03.280
optimization pass, such as, okay, you're using if on the constant, so you should, for example,

23:03.280 --> 23:13.520
use the, I don't remember the instruction in x86, 64, but the select, yeah, yeah, just seem with

23:13.600 --> 23:32.000
it, for example, yeah, yes, I'm not sure, I didn't understand, I can't extend your work,

23:32.000 --> 23:40.800
it will also have a biores, or the ratio of just enough. Yes, so the question is regarding to

23:40.800 --> 23:47.040
extend the work to other, so for example, card generation of the compiler, and yes, I would love to,

23:48.000 --> 23:58.320
but so far, since it's, we only want to first test these set of attributes, see if it fetch,

23:58.400 --> 24:06.160
we would love also to have feedback from cryptographic developers to see if, well, that much

24:06.160 --> 24:14.720
actual usability, and then, yeah, we would like to, after having an analysis, we're moving to fixing.

24:16.480 --> 24:22.240
Yeah, but the analysis will be done by the static analyzer, like doing all those preparations,

24:22.240 --> 24:26.800
and every speed, and then, I don't think, in the notes, in the simplest sequence of objects,

24:27.600 --> 24:34.240
so far, their classes will make use of the information, just take the rest. Thank you.

24:36.240 --> 24:41.840
So, I think there is a few questions behind, which is? No, I'm not, I'm actually excited because

24:41.840 --> 24:47.120
on the previous site, we have a similar issue with building biopivity. Okay, yeah, and for the first

24:47.120 --> 24:54.000
time, we are going to have to get the optimization passes to alter the behavior, not necessarily

24:54.000 --> 24:59.920
based on functionality requirements. Yeah, and what they see here is the same thing. Exactly, yeah,

25:00.480 --> 25:06.160
it's like the different, but it's the same, so we can't keep. Yeah, I would love to.

25:06.160 --> 25:17.360
Could you speak a bit loud? Could you speak a bit loud? Could you speak a bit loud?

25:17.360 --> 25:22.880
How do we take what a secret gets leaked? Like, do we have a major data based with all functions

25:22.880 --> 25:30.080
that are classified as leaking or how do we handle that? Okay, so the question is, how do we detect

25:30.080 --> 25:36.160
when the function is leaking? Actually, depends. Depends of your secret, depends of your model.

25:39.520 --> 25:47.440
For example, if you consider a constant time programming, you know that some function should never

25:47.440 --> 25:52.960
be used with secret, such as comparison function, such as the main compare or STLN,

25:53.680 --> 26:03.280
so some function like that, you know they should not. But outside of that, it depends.

26:04.480 --> 26:12.560
For example, in some context, I was thinking about STLN, and in other contexts, for example,

26:13.280 --> 26:19.920
so the length of a buffer, for example, as I said, in some context, the written value of STLN,

26:19.920 --> 26:25.520
for example, or the size of that buffer, will be secret. But in other case, you don't care.

26:26.800 --> 26:31.040
So that really depends on the project. So that's why we wanted to make it

26:33.200 --> 26:40.800
through a set of attributes. This is the user that have to set it in their headers, for example.

26:43.200 --> 26:48.560
I don't know if there's time yet. Yeah. Yeah, I am the last one. Let's go.

26:48.560 --> 26:51.360
Oh yes.

27:18.560 --> 27:20.560
things that you have to buy to a bottle?

27:20.560 --> 27:27.480
Yeah, for the question is regarding having the

27:27.480 --> 27:29.560
pain propagated between devices?

27:29.560 --> 27:30.560
No, no.

27:30.560 --> 27:32.560
Multiple different things.

27:32.560 --> 27:39.560
Oh, okay, so different things within the same, okay.

27:39.560 --> 27:43.560
So far, we haven't think about that to be honest.

27:43.560 --> 27:49.560
Yeah, I'm not sure if I can see a use case, like, because I'm not sure to understand

27:49.560 --> 27:50.560
the use case beyond it.

27:50.560 --> 27:51.560
Can you show us some examples?

27:51.560 --> 27:52.560
Yeah.

27:52.560 --> 27:55.560
Another example is the nearest product that we have a tool for class.

27:55.560 --> 27:56.560
Okay.

27:56.560 --> 28:00.560
The checks for points are compensation in which the best thing is the assignment.

28:00.560 --> 28:01.560
Oh, okay.

28:01.560 --> 28:02.560
Okay.

28:02.560 --> 28:07.560
As it points us, like all the ingredients you've pointed out are monetary, and then it checks

28:07.560 --> 28:08.560
out.

28:08.560 --> 28:09.560
Okay.

28:09.560 --> 28:25.560
So I think it might be, I mean, the base work would be the same, probably, but you have

28:25.560 --> 28:33.560
to redesign the propagation mechanism themselves.

28:34.560 --> 28:35.560
Okay.

28:35.560 --> 28:36.560
Yeah.

28:36.560 --> 28:37.560
Yeah.

28:37.560 --> 28:38.560
Okay.

28:38.560 --> 28:39.560
Okay.

28:39.560 --> 28:40.560
Okay.

28:40.560 --> 28:45.560
So the unsafe activity seems focused to me or other people, because

28:45.560 --> 28:47.560
every function is could be leaking.

28:47.560 --> 28:52.560
Can you kind of expect everybody to flag every function with the unsafe activity?

28:52.560 --> 28:53.560
Yes.

28:53.560 --> 28:54.560
Yeah.

28:54.560 --> 29:00.560
Most functions would be considered unsafe, and dealing with the secret has to be done

29:00.560 --> 29:06.560
properly with only specific functions that you have checked out for and so you can.

29:06.560 --> 29:09.560
And the, I said, that doesn't get, I can confirm myself.

29:09.560 --> 29:11.560
It's called Nensei explicit.

29:11.560 --> 29:12.560
Okay.

29:12.560 --> 29:13.560
That's, oh yeah, right.

29:13.560 --> 29:19.560
The presentation probably is that because the code in the display, the last two lines

29:19.560 --> 29:21.560
will be erased, but to my end.

29:21.560 --> 29:22.560
Yeah.

29:22.560 --> 29:23.560
Of course, yeah.

29:23.560 --> 29:24.560
Okay.

29:24.560 --> 29:25.560
So yeah.

29:25.560 --> 29:29.560
About this, I mean, yeah.

29:29.560 --> 29:35.560
The unsafe or safe, it's, I mean, it's a, it depends because for example, there's some function.

29:35.560 --> 29:39.560
You don't want to be able to flag them as safe.

29:39.560 --> 29:46.560
Depends of the programming language, of course, for example, additions in C++ or actually implementation.

29:46.560 --> 29:49.560
And so it's a function called, for example.

29:49.560 --> 29:54.560
So, and I don't know how it's, because I haven't looked at the gimbal as a say,

29:54.560 --> 29:56.560
an intermediate representation of C++.

29:56.560 --> 30:01.560
So, I don't know if, for example, addition is a function called or not.

30:01.560 --> 30:03.560
And it's the same.

30:03.560 --> 30:04.560
Okay.

30:04.560 --> 30:05.560
So, I'm not sure.

30:05.560 --> 30:06.560
I don't know.

30:06.560 --> 30:08.560
It's, yeah.

30:08.560 --> 30:10.560
I take the remark.

30:10.560 --> 30:12.560
I have to think about it.

30:12.560 --> 30:13.560
Thank you.

30:13.560 --> 30:14.560
I have an answer.

30:14.560 --> 30:15.560
I have an answer.

30:16.560 --> 30:18.560
Okay.

30:18.560 --> 30:21.560
Okay.

30:21.560 --> 30:22.560
Let's take care of it.

30:22.560 --> 30:25.560
Okay.

30:26.560 --> 30:28.560
You mean rest?

30:28.560 --> 30:31.560
No.

30:31.560 --> 30:35.560
And what I'm doing?

30:35.560 --> 30:36.560
Okay.

30:36.560 --> 30:37.560
Let's secure it.

30:37.560 --> 30:38.560
Yeah.

30:38.560 --> 30:39.560
Unsecured.

30:39.560 --> 30:40.560
Okay.

30:40.560 --> 30:42.560
Thank you.

30:42.560 --> 30:43.560
Thank you.

30:43.560 --> 30:44.560
Okay.

30:44.560 --> 30:46.560
Thank you.