593 entries in 0.188s
bvt: Ada.Sequential_IO is wired straight into fopen/fread/fwrite, by the way.
bvt: re syscalls -- fair enough. but imo this shows extreme brokeness of linux portability -- i can't think about a sane reason for syscall numbers to differ across arches.
bvt: asciilifeform: re exotic flags -- sure. but i don't expect different results with syscall numbers as well. some subset will match, later in the table -- complete mess
bvt: given that there is a single temporary file -- would ./ also work? ./tmp directory would have to be separately created and removed, and the less unix fs is touched, the better, i guess.
bvt: would you consider /tmp security issue resolved from vpatch's view if TMP/TMPDIR is respected?
bvt: hi, phf! i can provide a follow-up vpatch for respecting TMP/TMPDIR
bvt: comment approved, i would do a writeup on this topic (so far ETA middle of next week, this sunday night very optimistically).
bvt: i would much prefer going pure ada for a subset of posix. otherwise it's the same as relying on GNAT-specific packages -- it exports plenty of interesting stuff, not sure about networking though.
bvt: yes, i skimmed through it. all these sockaddr structures would be a bitch to do in ada. this is why i believe it would be useful to define, what subset we'd need.
bvt: well, for the library that i had in mind was strictly a database of flag name->int mappings, syscall numbers, maybe structure definitions.
bvt: i would try to make some sort of write-up about this. i wanted to suggest making a Ada library that exposes a subset of Linux system calls without C code, because i clearly needed it for the tempfile.
bvt: and the amount of damage is ridiculous, even errno codes are different on mips.
bvt: asciilifeform: re open flags: this is exactly what i was pointing at. should have made the text bold, i guess. if all these flags numbers were the same, i would have used the syscall wrapper functions.
bvt: !!v 314FFA01ECAE3BF4FD9863521D78063D3329D513BBF082B11172B54A17B8A7B3
bvt: !!pay-invoice BingoBoingo 1
bvt: thanks, i see what you mean. the Interfaces.C.Strings.New_String() comments explicitly say that the heap allocation is necessary for the large strings, which is not the case for vpatch temporary file names.
bvt: it seems that 'c strings' in ada are still controlled by ada mechanisms, i.e. they are ada strings (with bounds checking), just with null byte in the end
bvt: so no primer is necessary
bvt: i have my own painful experience with them
bvt: yes, these lockfiles are just a big mess.
bvt: the System/GNAT.OS_Lib find is interesting, i have missed it.
bvt: ave1, can you expand on getting rid of string allocations? I see a way to get rid of it for Mode, but not for the Path argument. i can move its c-string from heap to stack, but that would be it. anyhow, i will revise this aspect.
☟︎ bvt: btw, now vpatch.adb does not require Interfaces.C/Int.C.Strings for anything, they will go away in the revised vpatch.
☟︎ bvt: that's what I think as well
bvt: re naming: i agree that it clashes with Ada naming convention. will rename to Temporary_File.
bvt: should set everything up till the end of the week. i didn't rent a rk; but already tested pressing mp-wp locally.
☟︎ bvt: would love to hear your comments
bvt: should have implementation done over weekend
bvt: i will have a look at what primitives i need for the implementation today and tomorrow, and will come back here if i get stuck on something.
bvt: uhm, strace shows me here that the temporary filename changes
bvt: perhaps better way would be to create a temporary directory (for which there is atomic create-or-die) at the vpatch start, and place all temporary files there?
bvt: and i'm don't know yet if files created this way can be mv'ed to file system
bvt: there is a recent linux O_TMPFILE flag to open(2), but i'm not sure we want to use that
bvt: right, Ada.Directories.Exists was the missing piece.
bvt: i will give it a try. i'm still learning ada, will have to take a look at how strings and interfacing with C are done properly.
bvt: did you use ave1's gnat or the adacore-provided distro? My understanding is that it should work with both, taking 2 different code paths, and fail only with gnat17.
bvt: that was a wtf moment for me, i'm not used to such service from the runtime
bvt: I understand this, but still it's better to drop the vpatch, at least in the logs, in case someone else stumbles upon this problem.
bvt: Apparently those addresses are used as 'poor man's RNG'
bvt: There seems to be no useful code to take from GNAT for this problem.
bvt: 2. Ada internally uses mkstemp(3) to generate a random name when empty string is passed as filename to Open procedure.
bvt: decided to add some information to the yesterday's thread on mktemp use in vpatch:
bvt: iirc mkdir does atomic 'create or error-out'
bvt: I was man-aloning for quite some time
bvt: I was too naive when I entered academia. Hoped for honest investigation of technology, but everyone there seems to be ok with building on broken stuff.
bvt: Hello mircea_popescu!
bvt: "security", so in the end in boils down to handwaving problems away with TLS (aka pseudosecurity)
bvt: I live in germany, ukr by origin
bvt: I can't say I'm doing anything interesting in everyday life (PhDing in CS)
☟︎ bvt: well, I was reading logs for a really long time
bvt: Nope, ave1's is 2016
bvt: GNAT 2017, though, deletes such files on Close call.
bvt: GNAT 2016 runtime deletes all files with temp bits at the Finalization stage, so everything should work fine. (Not an ada specialist, so when finalization is actually run is a mistery to me)
bvt: but also sets a Temp bit in File record
bvt: empty string ("") is special-cased in GNAT runtime, which does mktemp equivalent internally
☟︎ bvt: sure, but I guess you are interested in explanation as well?
bvt: Sorry, don't have a WWW, but the fix should be a one-liner
bvt: I have a bug report for vpatch from phf
bvt: Hello, I am BT from the recent diana_coman's comments section
☟︎