<rqou>
it was funny when people were jailbreaking PSPs and iPhones, not so much anymore
<balrog>
rqou: tiff2pdf... as a contributor to that code I'm not surprised
* qu1j0t3
giggles
<rqou>
well yeah, you're combining two awful formats: TIFF, PDF :P
<balrog>
FAX IFD, PixarLogDecode
<balrog>
lol
<rqou>
although i've actually used tiff2pdf before as part of a rather convoluted process
<qu1j0t3>
it didn't actually work on my tiffs
<qu1j0t3>
i use the other tiffutils fairly regularly
<balrog>
it had issues with color space
<rqou>
scans of problem sets as jpg --> tiff using imagemagick? --> pdf using tiff2pdf --> one single pdf with multiple pages using pdftk
<rqou>
there was probably a better way
* qu1j0t3
has been working on deskewing
<rqou>
but I couldn't find the better way during the "homework is due in an hour" moment
<rqou>
lots of "important" code is really scary when you look at it
<rqou>
gnupg?
<rqou>
openssl?
<balrog>
qu1j0t3: have you used scantailor?
<qu1j0t3>
rqou: definitely.
* qu1j0t3
googles scantailor
<qu1j0t3>
balrog: I'll try it out.
<rqou>
i even fixed an out of bounds read in opensc (thing that does stuff with smartcards)
<rqou>
i don't think it was exploitable though
<qu1j0t3>
balrog: though i have a method that's very accurate on the docs i'm working on
<qu1j0t3>
balrog: and ones i've done for davedefeat
tecepe has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 276 seconds]
<azonenberg>
whitequark: rx devkit
<azonenberg>
they threw lots of fun stuff in there
<azonenberg>
another tape of slg46140s
<azonenberg>
another tape of slg46620s
<azonenberg>
a tape of slg46621s
<azonenberg>
(so now i have samples of every greenpak4)
* rqou
is fighting with postfix :P
<azonenberg>
as well as spare zif sockets for stqfn-14, 20, and even 12-pin 1.6x1.6 mm (not sure why they included that, i dont have any chips in that package)
<rqou>
why does mail delivery have way too many components?
<azonenberg>
rqou: we were just talking about this at work
<azonenberg>
its a disaster
<azonenberg>
relic from the days when people had internet access for a few minuts once a day
<cyrozap>
rqou: I was wondering what happened to f055.cc... Thanks for bringing it back!
<cyrozap>
That build script tho :P
<rqou>
yeah, it sucks
<rqou>
feel free to make a new one
<rqou>
my main website uses a giant monstrosity of Pelican
<rqou>
but I didn't want to require something like that
<cyrozap>
rqou: Yeah, I don't think we'd need anything fancy, just a little script to turn a TSV/CSV file into an HTML table and insert it into the main page, then a little CSS to make it pretty. No JS, no monstrous site generators.
carl0s has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
<azonenberg>
Welp
<azonenberg>
apparently i managed to break ipv4 on my dmz somehow
<azonenberg>
the box in question is able to reach the outside over ipv6
<azonenberg>
i think
* azonenberg
continues debugging
<azonenberg>
i have a new greenpak devkit that i want to get working in the VM...
carl0s has quit [Quit: Leaving]
amclain has quit [Quit: Leaving]
digshadow1 has quit [Quit: Leaving.]
digshadow has joined ##openfpga
tecepe has quit [Ping timeout: 260 seconds]
m_w has joined ##openfpga
massi has joined ##openfpga
m_w has quit [Quit: leaving]
kuldeep has quit [Remote host closed the connection]
kuldeep has joined ##openfpga
<azonenberg>
whitequark: jfyi i had to reimage Lucifer, ended up being unnecessary but i was trying to isolate some networking problems
<azonenberg>
so the ssh pubkey changed
<rqou>
lol
<rqou>
better than the time when the cs department here at UCB reimaged all of the computers in one of the labs
<rqou>
and forgot to announce it
<azonenberg>
rqou: this is a brand new vm that didnt have much on it yet
<azonenberg>
(like, anything)
<azonenberg>
it's got a greenpak devkit plugged into it
<azonenberg>
going to become a CI server soon
<rqou>
you couldn't live with it being ipv6-only? :P
<azonenberg>
itwas not ipv6 only
<azonenberg>
it was entirely down
<azonenberg>
there was, unrelated tothis issue
<azonenberg>
an ip address conflict
<azonenberg>
in which i was pinging the wrong box thinking this one was ok
<azonenberg>
didnt show up until i started up a vm i had had paused when i set up this one
digshadow has quit [Ping timeout: 260 seconds]
digshadow has joined ##openfpga
carl0s has joined ##openfpga
clifford has joined ##openfpga
carl0s has quit [Quit: Leaving]
Bike has quit [Quit: leaving]
massi has quit [Read error: Connection reset by peer]
massi has joined ##openfpga
<rqou>
offtopic: does anyone know if dovecot can disable tls session resumption using tickets?
<rqou>
why is PFS hard?
<cr1901_modern>
I don't remember having to do any of that when setting up dovecot
<cr1901_modern>
Then again, if you asked me to set up a mail server right now, I prob couldn't do it without help
* cr1901_modern
is still kinda amazed he was able to do it at all. It's not hard, but it's involved.
tecepe has joined ##openfpga
<DocScrutinizer05>
whitequark: azonenberg: do you know how silego GP5 handles I2C addr configuration? we have " reg<1867:1864> I2C Control Code Bit [3:0] is protected from I2C write" however in devboard emulation mode I suppose the chip is expected to have the correct I2C addr set up in RAM only, without flashing it to NVM
<DocScrutinizer05>
azonenberg: related: I wondered if Silego wouldn't want to offer 16 different flavors of their "unrpogrammed" chips that simply have the 16 possible I2C addresses preprogrammed but allow flashing the rest of NVM to your liking
<DocScrutinizer05>
background is that silego recently gone pretty "hostile" about chip programming service - it's only available MOQ 3k now
<DocScrutinizer05>
so our project which needs a total of 3k chips but in 3 1k batches with different I2C addr, we would have to manually program and retape 2k chips, which is a royal PITA
<DocScrutinizer05>
for a very optimistic 30s per chip for unpacking, inseriting to devboard, programming, removinf from ZIF socket and placing into tape again, we are at 3 days of brainkilling work
<DocScrutinizer05>
[2016-10-20 Thu 21:56:59] <cyborgar_> DocScrutinizer05, c4757p, Silego said this on low end "I would expect that if you ordered a 3k pc T/R of a GreenPAK5 that was only trimmed and had an I2C address programmed in it, you would find other uses for them in other projects. :-)"
<DocScrutinizer05>
WTF? if they expect that those chips are easy to resell then why don't hey offer them like this right away??
<DocScrutinizer05>
azonenberg: do you know if the GP NVM can get flashed multiple times, as long as only 0>1 bit changes?
<DocScrutinizer05>
(or 1->0, whatever applies. Too lazy to read out NVM of an unprogrammed chip)
<wpwrak>
DocScrutinizer05: such a readout would actually be interesting. also to see if one could actually operate a silego from the "default address"
<DocScrutinizer05>
general call would be the way to implement an ENUM though
<DocScrutinizer05>
still the SG chip needs a way to know about own identity and role, so unless we have some ID flashed into NVM, we need a GPIO based role assignment
<DocScrutinizer05>
any random delay or somesuch won't help to make chips aware of own role, even when it helps to arbit between addr assignment collisions
DocScrutinizer05 has quit [Excess Flood]
DocScrutinizer05 has joined ##openfpga
<DocScrutinizer05>
any random delay or somesuch won't help to make chips aware of own role, even when it helps to arbit between addr assignment collisions // a possibly workable scheme would be to upload a ENUM config via "general call" addr, and the fastest chip grabs a new unique addr, then you talk to the chip via that addr and you read state of all GPIO and try to find out about the role of that chip // (always assuming we could config I2C addr via
<DocScrutinizer05>
I2C somehow) // now, way past time to leave flat, afk, bbl
doomlord has joined ##openfpga
digshadow1 has joined ##openfpga
azonenberg_work has joined ##openfpga
digshadow has quit [Ping timeout: 260 seconds]
<wpwrak>
if the chip had a unique ID, a host could learn it simply by clocking it out of the chips, provided that each chip checks if the data on bus disagrees with the data it is sending, and in this case ends its participation in the readout. at the end of the readout, the host could assign the bus address, be it by addressing the chip directly (with the ID it has learned) or by just sending the bus address at the end (then it could even ignore the unique addr
<wpwrak>
ess)
<wpwrak>
but all this would require a protocol architecture that doesn't cause conflicting behaviour in chips that don't know of this protocol
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
digshadow1 has quit [Quit: Leaving.]
bibor has quit [Read error: Connection reset by peer]
bibor has joined ##openfpga
amclain has joined ##openfpga
m_w has joined ##openfpga
digshadow has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
[X-Scale] is now known as X-Scale
Bike has joined ##openfpga
doomlord has joined ##openfpga
massi has quit [Remote host closed the connection]
mIKEjONE1 is now known as mIKEjONES
<rqou>
cr1901_modern: you don't HAVE to disable session tickets
<rqou>
it just makes perfect forward secrecy slightly better
<rqou>
a session ticket essentially contains the secret session state of a connection encrypted with a symmetric key that the server holds
<rqou>
it allows you to reconnect TLS without doing all the key exchange again
<rqou>
the problem is that if you capture a session ticket and then much later obtain the session ticket key, you can break that connection's encryption