I made symbolic links “ln -s /etc/ssl/cert.pem ”. I used the
realpath command and it worked in the software I submitted.
On Thu, Jun 4, 2020 at 11:06 AM Theo de Raadt wrote:
> No.
>
> I'm guessing you don't understand symbolic links.
>
> Look, this is a waste of time.
>
>
> Luke Small wrote:
>
In the case of 1 URLs couldn’t you at least merely unveil “./“ as “cw”;
make any specified cafile/capath including shortcut resolution as “r”
(perhaps with the shell “x”) so that at worst, current directory files
could be overwritten, but not read?
On Wed, Jun 3, 2020 at 10:39 AM Theo de Raadt
No.
I'm guessing you don't understand symbolic links.
Look, this is a waste of time.
Luke Small wrote:
> --80daf105a7444c30
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: 8bit
>
> In the case of 1 URLs couldnât you at least merely unveil â./â a
there was tiny error I created.
-Luke
On Wed, Jun 3, 2020 at 2:24 PM Luke Small wrote:
> There! It doesn't use an unveil list. It has 2 dry runs as proposed.
> It could just have a dry run to see if it goes into interactive mode
> and then unveil as we go! but I like to see all the unveil calls
There! It doesn't use an unveil list. It has 2 dry runs as proposed.
It could just have a dry run to see if it goes into interactive mode
and then unveil as we go! but I like to see all the unveil calls before
the ftp output statements myself!
-Luke
On Wed, Jun 3, 2020 at 11:30 AM Luke Small wro
Or you could have 2 dry runs. One to merely see that it won't head into
interactive mode
and a second one to start the unveiling directly in fetch.c. Unless unveil
itself will
have too many entries!
-Luke
On Wed, Jun 3, 2020 at 11:12 AM Luke Small wrote:
> I figure if it took up that much stack
I figure if it took up that much stack space from before, it'd start
needing to
dang near run the stack into on-disk virtual memory anyway. At that point,
it'd perhaps be a better design choice to break up your ftp calls into
slightly
smaller chunks to avoid massively poor performance, yeah? LOL
I
You really don't get it.
+ unveil_list = calloc(2 * argc, sizeof(char*));
Imagine argc is 1.
+ for (i = 2 * argc - 2; i >= 0; i -= 2) {
+ if (unveil_list[i]) {
+ if (unveil(unveil_
I’ll be the first to admit that I don’t completely understand the power
that is the ftp client. but what I do understand of it, from the
perspective of noninteractive commandline execution, it seems to fit the
bill. For file and http(s) transfers. I didn’t see any buffer overflows and
I’m sure that
I mean it is amusing, because this is never going to fly.
This increase in complexity is completely unacceptable, what I see is
completely amateurish, and I also see overflows, a lack of testing
for edge conditions, and a lack of attention to how unveil works.
Luke Small wrote:
> You're welcom
You're welcome! I figured you might not want a “massive” diff to cap off
your day to make a program that you apparently feel is secure enough, but I
made good that I got off my ass and did something anyway. I’m surprised
that you even went to the trouble of pledging it myself. It only took 2 or
3 d
Thank you for the laugh.
Luke Small wrote:
> I think I'm done tinkering. try these out in ftp folder. I left in some
> fprintf(ttyout,...) in main.c
> to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
> and SSL_PATH variables.
> It leaves in place the functionality of the orig
I think I'm done tinkering. try these out in ftp folder. I left in some
fprintf(ttyout,...) in main.c
to show what is being unveiled. It resolves shortcuts in SSL_CAFILE
and SSL_PATH variables.
It leaves in place the functionality of the original functions, but adds
the availability to perform
a dr
13 matches
Mail list logo
