Can anyone help me decoding below crash log from iPhone Configuration utility of iPhone Device
Oct 19 11:09:18 iPhone-AIPV02 kbd[1099] <Warning>: -[TIXPCDataTransport _handleForPurpose:withReplyBlock:] couldn't get data source for purpose=__TIRDTUD
Oct 19 11:09:18 iPhone-AIPV02 mClient[1096] <Warning>: __47+[TIUserDictionaryController loadWordKeyPairs:]_block_invoke_0 Received nil NSData for TIRemoteDataUserDict
Oct 19 11:09:20 iPhone-AIPV02 librariand[1100] <Notice>: MMe quota status changed: under quota
Oct 19 11:09:35 iPhone-AIPV02 lockdownd[29] <Notice>: 2fe93000 spawn_and_handle_checkin: Timeout on socket /var/run/lockdown/checkin.1012 waiting for com.apple.crashreportmover to checkin for Xcode. spawn=1350625160 select=1350625160 now=1350625175
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Warning>: Not internal build
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Notice>: Saved crashreport to /Library/Logs/CrashReporter/stacks-2012-10-19-110935.plist using uid: 0 gid: 0, synthetic_euid: 0 egid: 0
Oct 19 11:09:35 iPhone-AIPV02 ReportCrash[1103] <Error>: libMobileGestalt copySystemVersionDictionaryValue: Could not lookup ReleaseType from system version dictionary
Oct 19 11:09:39 iPhone-AIPV02 com.apple.debugserver-189[1095] <Warning>: 1 +0.000000 sec [0447/0303]: error: ::ptrace (request = PT_THUPDATE, pid = 0x0448, tid = 0x2503, signal = 0) err = Resource busy (0x00000010)
Oct 19 11:09:39 iPhone-AIPV02 com.apple.debugserver-189[1095] <Warning>: 2 +0.033249 sec [0447/0303]: error: ::task_threads ( task = 0x1603, thread_list => 0x0, thread_list_count => 0 ) err = (os/kern) invalid argument (0x00000004)
Oct 19 11:09:39 iPhone-AIPV02 com.apple.debugserver-189[1095] <Warning>: 3 +0.000988 sec [0447/0303]: error: ::task_info ( target_task = 0x1603, flavor = TASK_BASIC_INFO, task_info_out => 0x2fdbee6c, task_info_outCnt => 8 ) err = (os/kern) invalid argument (0x00000004)
Oct 19 11:09:39 iPhone-AIPV02 com.apple.launchd[1] (UIKitApplication:com.csam.app.mClient[0x2ae5][1096]) <Notice>: (UIKitApplication:com.csam.app.mClient[0x2ae5]) Exited: Killed: 9
Oct 19 11:09:39 iPhone-AIPV02 com.apple.debugserver-189[1095] <Warning>: 4 +0.025519 sec [0447/1303]: error: ::read ( 5, 0x2ff22a0c, 1024 ) => -1 err = Bad file descriptor (0x00000009)
O
on my Xcode console I can only see below log and then My iPhone Device gets Restart
2012-10-19 11:09:18.234 mClient[1096:907] __47+[TIUserDictionaryController loadWordKeyPairs:]_block_invoke_0 Received nil NSData for TIRemoteDataUserDict
Apart from this if I see my Crash log on Device then I am getting very strange Logs as below It shows me Unknown app name in Organizer..
Incident Identifier: C0A41418-FFB1-480F-9407-3DCABDF8C817
CrashReporter Key: 424c30662723fd3ef8386fa097c54696af46b054
Hardware Model: iPhone3,3
OS Version: iPhone OS 6.0 (10A403)
Kernel Version: Darwin Kernel Version 13.0.0: Sun Aug 19 00:27:34 PDT 2012; root:xnu-2107.2.33~4/RELEASE_ARM_S5L8930X
Date: 2012-10-19 11:07:25 +0530
Time since snapshot: 348 ms
Free pages: 945
Active pages: 7743
Inactive pages: 3807
Throttled pages: 19087
Purgeable pages: 9
Wired pages: 96860
Largest process: mClient
Processes
Name <UUID> rpages recent_max [reason] (state)
timed <f3f0e010a9a13ae69b5761a5db3f4a3c> 231 231 [vm] (daemon) (idle)
accountsd <ac0fce15c1a2350d951efc498d521ac7> 240 240 [vm] (daemon) (idle)
afcd <b0aff2e7952e34a9882fec81a8dcdbb2> 117 117 [vm] (daemon) (idle)
networkd_privile <f8858e6f66af39ab8ce8f105cfa6872f> 94 94 [vm] (daemon) (idle)
installd <309cd72e8af43ad1b77d96274d0b0ff7> 310 310 [vm] (daemon) (idle)
lsd <6a9f5b5f36b23fc78f87b6d8f1f49a9d> 270 270 [vm] (daemon) (idle)
MobilePhone <3fca241f2a193d0fb8264218d296ea41> 1771 1771 [vm] (resume) (continuous)
librariand <c9a9be81aa9632f0a913ce79b911f27e> 199 199 [vm] (daemon)
tccd <eb5ddcf533663f8d987d67cae6a4c4ea> 124 124 [vm] (daemon)
kbd <3e7136ddcefc3d77a01499db593466cd> 545 545 [vm] (daemon)
mClient <2a2692e6564f30e1b683883adb7cb323> 97400 98186 [vm] (frontmost) (resume)
ptpd <04a56fce67053c57a7979aeea8e5a7ea> 837 837 [vm] (daemon)
assistivetouchd <1f4670e8371f3afbaaee4898c459e148> 1141 1141 [vm] (daemon)
syslogd <cbef142fa0a839f0885afb693fb169c3> 117 170 [vm] (daemon)
wifid <9472b090746237998cdbb9b34f090d0c> 366 366 [vm] (daemon)
locationd <892cd1c9ffa43c99a82dba197be5f09e> 1199 1199 [vm] (daemon)
mediaserverd <80657170daca32c9b8f3a6b1faac43a2> 463 463 [vm] (daemon)
iaptransportd <f784f30dc09d32078d87b450e8113ef6> 234 234 (daemon)
SpringBoard <27372aae101f3bbc87804edc10314af3> 3371 3371
backboardd <5037235f295b33eda98eb5c72c098858> 3131 3131 (daemon)
UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90> 404 404 (daemon)
geod <73e79779d11a312cb70c3770e494ceab> 266 266 (daemon)
springboardservi <ff6f64b3a21a39c9a1793321eefa5304> 0 0 (daemon)
distnoted <a89af76ec8633ac2bbe99bc2b7964bb0> 101 101 (daemon)
notification_pro <845b7beebc8538ca9ceef731031983b7> 118 118 (daemon)
filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 127 127 (daemon)
apsd <94d8051dd5f5362f82d775bc279ae608> 337 337 (daemon)
networkd <0032f46009f53a6c80973fe153d1a588> 157 157 (daemon)
aggregated <8c3c991dc4153bc38aee1e841864d088> 87 87 (daemon)
debugserver <185719f06f1631d4922c652bdd4c8529> 0 0 (daemon)
powerd <2d2ffed5e69638aeba1b92ef124ed861> 132 132 (daemon)
ubd <74dc476d1785300e9fcda555fcb8d774> 336 336 (daemon)
mDNSResponder <3e557693f3073697a58da6d27a827d97> 280 280 (daemon)
lockdownd <ba1358c7a8003f1b91af7d5f58dd5bbe> 192 192 (daemon)
BTServer <c92fbd7488e63be99ec9dbd05824f5e5> 407 407 (daemon)
configd <4245d73a9e96360399452cf6b8671844> 396 396 (daemon)
fairplayd.N92 <db9f16dba3f8358e9b49b446eea2f186> 137 137 (daemon)
fseventsd <996cc4ca03793184aea8d781b55bce08> 288 288 (daemon)
imagent <1e68080947be352590ce96b7a1d07b2f> 298 298 (daemon)
lockbot <4ab4aa38f8b530c984dd4840506f8b08> 228 418 (daemon)
syncdefaultsd <991361b1e471398499afeeb750d132f1> 221 221 (daemon)
CommCenter <1f425e1e897d32e8864fdd8eeaa803a8> 616 616 (daemon)
notifyd <51c0e03da8a93ac8a595442fcaac531f> 149 149 (daemon)
**End**
Restart your phone. I had these errors occurring and things like the camera app would crash, they started occurring when my device ran out of space, I deleted a bunch of files but the errors stayed... I restarted my phone and all worked well, I thought to do this because when I would test the app on other devices it worked fine and these errors didn't occur.
I just had the same problem with the same [TIUserDictionaryController loadWordKeyPairs:]... error. I noticed I had one of my UITextFields's delegate set to File's owner but wasn't using the delegate. I removed the textField's delegate (from my storyboard file), and all worked well :)
It was weird though, cause everything was working fine for days with testing, I submitted the app for review, and 3 days later I tried to show someone the app, and it kept crashing out of nowhere. Perhaps it's some strange bug in Apple's UITextField class
Related
For the following dataset which has multi-indexes Activity->Facility Size->Year
my goal is to apply style.highlight_max() & style.highlight_min() for Column (Employee Count) in each group individually (Large, Medium, and Small),is there a way to do it while still maintaining the same shape of the dataframe as below without separating each group apart.
Facility Count Employee Count \
Activity Facility Size Year
Computer Programming Large 2010 59 3830
2011 60 3912
2012 63 4111
2013 66 4273
2014 73 4730
2015 81 5066
2016 85 5347
2017 86 5426
2018 86 7256
Medium 2010 168 1418
2011 179 1509
2012 190 1601
2013 191 1615
2014 211 1779
2015 228 1922
2016 229 1972
2017 233 2017
2018 235 2640
Small 2010 182 431
2011 185 438
2012 194 459
2013 202 478
2014 226 535
2015 226 572
2016 235 604
2017 243 623
2018 244 687
I have tried getting each group separately by using .groupby(level=0) but that is not what I want since it separates each group apart not as one dataframe
Thank you
I used the website diagrams.net to create a figure with some mathematical expressions. Of course, I can export it how PNG and import it to my Overleaf, but I want to retain the vectorization of the expressions. Because of that, I am trying to import it how PDF inside my Overleaf document.
When I use:
\begin{figure}[tbp!]
\centering
\includegraphics[width=\linewidth]{images/math_structure.pdf}
\caption{My figure description.}
\label{fig:math_structure}
\end{figure}
My figure is shown normally, aparently, but when I zoom in the mathematical expressions I have it:
Another interesting thing I noted is that when I download the PDF from Overleaf and open it using MUPDF the "bold" disappears, but when I open it using Google Chrome or Firefox the "bold" is there yet.
This is a pretty strange thing because I guess it was a problem of embedding font inside the PDF, but my file opens normally in MUPDF. Does anyone know what is happening and how can I resolve it?
I am sharing the math_structure in order to reproduce the problem in the following link: PDF
As an addendum to K J's answer:
looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator? here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
Indeed, all those items with a glow are drawn twice in the content stream, once for filling the defining path, once for stroking. E.g. the capital S of "State":
.111484379 0 0 -.111468516 140.764496 314.20746 cm
/G3 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
f
/G7 gs
55 507 m
55 562.33331 74 609 112 647 c
150 685 193.66666 704 243 704 c
257 704 l
313.66666 704 363 683 405 641 c
426 672 l
429.33334 676.66669 432.66666 681.66669 436 687 c
439.33334 692.33331 442.66666 696.66669 446 700 c
449 704 l
449.66666 704 451 704 453 704 c
455 704 457 704.33331 459 705 c
463 705 l
465 705 468 703 472 699 c
472 462 l
466 456 l
448 456 l
440.66666 456 436.33334 457 435 459 c
433.66666 461 432 467.66666 430 479 c
418.66666 563 385 618.66669 329 646 c
304.33334 656.66669 279.33334 662 254 662 c
218.66666 662 190 650 168 626 c
146 602 135 574 135 542 c
135 519.33331 140.666672 498.66666 152 480 c
163.333328 461.33334 179.33333 446.33334 200 435 c
206.66667 432.33334 235.33333 424.66666 286 412 c
336.66666 399.33334 364.66666 391.66666 370 389 c
408 374.33334 439 349.33334 463 314 c
487 278.66666 499.33334 237.66667 500 191 c
500 137 482.66666 88.333336 448 45 c
413.33334 1.66666412 364.33334 -20.333334 301 -21 c
263.66666 -21 230.33333 -15.333334 201 -4 c
171.66667 7.333334 151.333328 17.666666 140 27 c
122 41 l
119.333336 37.666668 114.333336 31 107 21 c
99.666664 11 93 1.66666698 87 -7 c
81 -15.666667 78 -20.333334 78 -21 c
76.666664 -21.666666 73.333336 -22 68 -22 c
64 -22 l
62 -22 59 -20 55 -16 c
55 101 l
55 180.33334 55.333332 220.66667 56 222 c
57.333332 225.33333 64 227 76 227 c
89 227 l
93 223 95 218.66667 95 214 c
95 192.66667 98.333336 171.66667 105 151 c
111.666664 130.333328 123 110 139 90 c
155 70 177 54 205 42 c
233 30 266.33334 24 305 24 c
336.33334 24 363.33334 36.666664 386 62 c
408.66666 87.333336 420 118.333328 420 155 c
420 183.66667 412.66666 209.66667 398 233 c
383.33334 256.33334 364 272.33334 340 281 c
302.66666 290.33334 278 296.66666 266 300 c
262.66666 300.66666 253.66667 302.66666 239 306 c
224.33333 309.33334 213.33333 312 206 314 c
198.66667 316 188 319.66666 174 325 c
160 330.33334 149 336.33334 141 343 c
133 349.66666 123.333336 357.66666 112 367 c
100.666664 376.33334 91.666664 388 85 402 c
65 434.66666 55 469.66666 55 507 c
h
S
The filled version is drawn with the extended graphics state G3, the stroked version is drawn with the extended graphics state G7.
G3 fills in an opaque manner:
<</BM/Normal/ca 1>
but G7 strokes very transparently (opacity .1098) and sets some other parameters:
<</BM/Normal/CA .1098/LC 0/LJ 0/LW 0/ML 4/SA true/ca .1098>>
But in particular G7 also sets the line width to 0 (the thinnest line that can be rendered at device resolution: 1 device pixel wide).
The OP mentions that they see the shadows when they zoom in. Thus, maybe those viewers in which you see a broad shadow/glow after zooming do simply zoom by drawing everything magnified by the zoom factor, i.e. the shadow/glow becomes zoom factor * 1 pixel wide; and those viewers in which you don't see a broad shadow/glow draw the outlines even after zooming with a 1 pixel width.
It does not appear to be the difference is in the font style since the weighting between standard 24 and bold 24 is shown below on the right. Which is not evident in your two samples.
However, what is noticeable in your sample is the "shadows" around each of those letter on the left giving the impression of extra thickness.
Initially I would expect that could be caused by the difference between jpeg (haloed lettering) and png (crisp anti-alias outlines). But then the shadow is too regular i.e. not uneven like it would normally be in a jpeg.
At this stage it looks like there may be some other reason for such fuzzy fonts.
Without a sample I would have to guess the PDF has potentially a font with an alpha component but could be way off in such a wild assumption.
Later Edit
Thanks for your link but the mystery deepens, since that linked PDF in Chromium Edge even enlarged shows no evidence of any shadows, but then again the maths looks like vector outlines only the middle Tahoma appears to be font and the one embedded, as generated by Skia/PDF thus built by chrome?.
I have to agree there is some other influence somewhere down the line but the browser should not affect the PDF unless it adds or respects some overlay based on an extra component, and looking at each letter there are two objects so although I can not see the shadow within the editor but accept it is there so it must be placed by the text outline generator?
here I have moved and coloured some glyphs so the second edge is deliberate but most viewers would not show them as a "GLOW"
You mentioned "diagrams.net" which does have many shadow options but I never experienced any other than deliberately set to right and down. Perhaps look for a rogue setting there.
In summary the file is declared as compatible with version 1.4 (may have transparency) and clearly some transparent objects have been included around each letter! but not in a fashion expected by all viewers. As a result of #mkl 's observation I retested the pdf in many viewers with the settings that could have an effect such as vector line thickening in acrobat, However NONE I tested showed the extra thick outlines, thus the PDF seems valid but some PDF viewer(apps) methods you are using seem to thicken the anti-alias much more than should be expected for a single pixel boundary.
Note: I've already read the very good answer to this question, but it doesn't answer my issues.
I'm attempting to implement SCRAM-SHA1 authentication standard, as specified by RFC 5802, in Common Lisp. I am running into issues when it comes to generating the client final response message.
This is the code of the function (the rest of the functions are available here) -- this is an attempt to implement the algorithm as described on page 7 of the RFC:
(defun gen-client-final-message
(&key password client-nonce client-initial-message server-response)
(check-type client-nonce string)
(check-type client-initial-message string)
(check-type server-response string)
(check-type password string)
"Takes a password, the initial client nonce, the initial client message & the server response.
Generates the final client message, and returns it along with the server signature."
(progn
(if (eq nil (parse-server-nonce :nonce client-nonce :response server-response)) NIL)
(let* ((final-message-bare (format nil "c=biws,r=~a" (parse-server-nonce :nonce client-nonce
:response server-response)))
(salted-password (ironclad:pbkdf2-hash-password
(ironclad:ascii-string-to-byte-array password)
:salt (ironclad:ascii-string-to-byte-array
(parse-server-salt :response server-response))
:digest :sha1
:iterations (parse-server-iterations :response server-response)))
(client-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Client Key")))
(stored-key (gen-sha1-digest :key client-key))
(auth-message (format nil "~a,~a,~a"
client-initial-message
server-response
final-message-bare))
(client-signature (gen-hmac-digest :key stored-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(client-proof (integer->bit-vector (logxor (ironclad:octets-to-integer client-key)
(ironclad:octets-to-integer client-signature))))
(server-key (gen-hmac-digest :key salted-password
:message (ironclad:ascii-string-to-byte-array "Server Key")))
(server-signature (gen-hmac-digest :key server-key
:message (ironclad:ascii-string-to-byte-array auth-message)))
(final-message (format nil "~a,p=~a"
final-message-bare
(base64-encode (write-to-string client-proof)))))
(pairlis '(final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)
(list final-message
final-message-bare
salted-password
client-key
stored-key
auth-message
client-signature
client-proof
server-key
server-signature)))))
The example conversation in the RFC uses the username user and the password pencil:
C: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
S: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,
i=4096
C: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,
p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
S: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
Taking the same server response (r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096) and feeding it into my function, I get:
* (cl-scram:gen-client-final-message :password "pencil" :client-nonce "fyko+d2lbbFgONRv9qkxdawL" :client-initial-message "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL" :server-response "r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096")
((CL-SCRAM::SERVER-SIGNATURE
. #(33 115 21 228 67 190 35 238 223 122 117 125 222 242 209 136 175 228 67
151))
(CL-SCRAM::SERVER-KEY
. #(15 224 146 88 179 172 133 43 165 2 204 98 186 144 62 170 205 191 125 49))
(CL-SCRAM::CLIENT-PROOF
. #*1100100111101011000000111010100000010101011001000101011100110001111100001100100010001101001000110101001010101010001011111000100011100001001110100001001110000)
(CL-SCRAM::CLIENT-SIGNATURE
. #(251 9 164 14 244 111 236 112 227 116 148 143 243 255 231 75 58 114 21
88))
(CL-SCRAM::AUTH-MESSAGE
. "n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::STORED-KEY
. #(233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43
214))
(CL-SCRAM::CLIENT-KEY
. #(226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87
40))
(CL-SCRAM::SALTED-PASSWORD
. #(29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125))
(CL-SCRAM::FINAL-MESSAGE-BARE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j")
(CL-SCRAM::FINAL-MESSAGE
. "c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=IyoxMTAwMTAwMTExMTAxMDExMDAwMDAwMTExMDEwMTAwMDAwMDEwMTAxMDExMDAxMDAwMTAxMDExMTAwMTEwMDAxMTExMTAwMDAxMTAwMTAwMDEwMDAxMTAxMDAxMDAwMTEwMTAxMDAxMDEwMTAxMDEwMDAxMDExMTExMDAwMTAwMDExMTAwMDAxMDAxMTEwMTAwMDAxMDAxMTEwMDAw"))
As you can see, my client-proof (the p= part of the final-message) is wildly different to the one in the example.
I added all of the intermediate variables to the return in case anyone here can see what's going wrong. Unfortunately, there are no examples which show the intermediate variable values, so I can't compare what I'm getting to the alternatives.
The intermediate values for the sample in the RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms are on the bottom of this answer.
Your p value is way too long; you are probably encoding the bits as string instead of bytes. You should loop over the byte blocks and XOR each unsigned byte separately. Converting to integer, then to bit string, then back to octet string is going to fail because it will probably remove the most significant zero bits. Once you've got the XOR'ed octet string you can base 64 encode it.
Furthermore, you need to remove n,, from the start of your AuthMessage, as specified in the RFC.
For future developers, without further ado, the intermediate values:
In base 64:
SaltedPassword: HZbuOlKbWl+eR8AfIposuKbhX30=
ClientKey: 4jTEe/bDZpbdbYUrmaqiuiZVVyg=
StoredKey: 6dlGYMOdZcOPutkcNY8U2g7vK9Y=
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: XXE4xIawv6vfSePi2ovW5cedthM=
ClientProof: v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
Using decimal arrays:
SaltedPassword: 29 150 238 58 82 155 90 95 158 71 192 31 34 154 44 184 166 225 95 125
ClientKey: 226 52 196 123 246 195 102 150 221 109 133 43 153 170 162 186 38 85 87 40
StoredKey: 233 217 70 96 195 157 101 195 143 186 217 28 53 143 20 218 14 239 43 214
AuthMessage: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
ClientSignature: 93 113 56 196 134 176 191 171 223 73 227 226 218 139 214 229 199 157 182 19
ClientProof: 191 69 252 191 112 115 217 61 2 36 102 201 67 33 116 95 225 200 225 59
I get syntax error while running this script in AMPL. Can someone help me to solve this?
param K;
param N;
param PT;
param beta_lower{1..K};
param beta_upper{1..K};
set KSET := {1 . . K};
set NSET := {1 . . N};
param Channel {KSET,NSET};
var V
var C {KSET, NSET} binary;
#==================================
data;
param K:=2;
param N:=64;
param PT:= 1;
param beta_lower:= 1 1.99 2 3.99;
param beta_upper:= 1 2.01 2 4.01;
param Channel : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 :=
1 1366 1474 1583 1690 1790 1881 1963 2036 2101 2161 2217 2268 2315 2355 2385 2402 2403 2386 2350 2295 2223 2137 2041 1939 1835 1734 1639 1553 1479 1419 1375 1347 1335 1339 1357 1386 1421 1459 1494 1523 1542 1548 1540 1520 1490 1451 1409 1364 1321 1279 1239 1201 1164 1127 1092 1060 1034 1016 1012 1024 1055 1107 1178 1265
2 1297 1281 1250 1201 1135 1055 963 867 772 685 611 555 519 504 510 536 579 636 702 775 851 928 1002 1074 1143 1209 1276 1345 1420 1503 1596 1698 1808 1921 2033 2137 2225 2290 2327 2333 2309 2256 2180 2089 1989 1890 1796 1712 1641 1582 1533 1493 1458 1425 1393 1364 1337 1314 1298 1289 1288 1292 1297 1301;
I write this piece of code in tex file (.rtf) and upload this to neos-server
The output from the solver is:
amplin, line 7 (offset 54):
syntax error
context: >>> {\ <<< rtf1\ansi\ansicpg1252\cocoartf12processing commands.
Executing on neos-2.neos-server.org
Error (2) in /opt/ampl/ampl -R amplin
The problem is that you mix syntax for AMPL model and data in your code. In particular, you should first declare parameter beta_lower in the model:
param beta_lower{1..K}; # you may want a different indexing expression here
and then provide data for it in the data section:
data;
param beta_lower:= 1 1.99 2 3.99;
Your updated formulation looks correct, but the error indicates that it is in RTF format. To make it work you should convert it into plain text.
I have an rsa.PublicKey object (retrieved from an rsa.PrivateKey). And I'm trying to export it into the OpenSSH format, to display it in a web page.
I've noticed the go.crypto/ssh library, which seems to be doing this.
And there's the discussion about it's implementation (it's actually exactly what I need to do)
Unfortunately, I'm getting a bit stuck, as the byte array returned is in an unknown encoding and I can't just transform it to a string to display it.
func PublicKey(rsaKey rsa.PublicKey) string {
key, _ := ssh.NewPublicKey(&rsaKey)
marshalled := ssh.MarshalPublicKey(key)
return string(marshalled)
}
This seems to work as it adds the ssh-rsa at the beginning of the string. However, most characters aren't recognized.
Here's the bytes array I'm retrieving for a lambda public key:
[0 0 0 7 115 115 104 45 114 115 97 0 0 0 3 1 0 1 0 0 0 65 0 178 153 15 73 196 125 250 140 212 0 174 106 77 27 138 59 106 19 100 43 35 242 139 0 59 251 151 121 10 222 154 76 200 43 139 42 129 116 125 222 192 139 98 150 229 58 8 195 49 104 126 242 92 75 244 147 107 161 192 230 4 30 157 21]
Any hint on properly displaying this bytes array as a string?
Marshaling a key is for the wire format. You just need to base64 encode the bytes:
base64.StdEncoding.EncodeToString(marshalled) + "\n"