> 1. Have multiple LLMs scrutinize every pull request that is created in the public.
---
> You:
> Below is a hexdump of a test file added to our code repository. Is it any cause for concern?
```
0000000 375 7 z X Z \0 \0 004 346 326 264 F 002 \0 ! 001
0000010 \b \0 \0 \0 330 017 # 023 001 \0 \f # # # # H
0000020 e l l o # # # # \0 \0 \0 \0 022 210 337 004
0000030 Y r 201 B \0 001 % \r q 031 304 266 037 266 363 }
0000040 001 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004
0000050 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023
0000060 340 005 026 001 _ ] \0 005 245 - U 273 230 004 |
0000070 306 231 274 240 f M 315 1 255 \v ) 270 ( \f .
0000080 274 3 263 ~ * 323 312 n 324 C 034 Q Y 314 217 341
0000090 350 343 357 @ 227 271 247 w 026 255 237 U * H 367 240
00000a0 K 260 p 9 5 370 j 017 203 ? 307 ] 005 326 220 240
00000b0 352 I 236 ` ? 304 306 365 246 375 226 [ 257 a 177 -
00000c0 261 033 204 001 203 251 346 252 243 244 < 016 h 256 273 356
00000d0 320 206 ! 355 367 P ) 247 035 226 357 026 224 324 u K
00000e0 255 8 277 326 350 347 205 \n : 220 334 342 u 216 M 357
00000f0 \f = c 316 244 % \0 233 E 354 x " 376 250 266 247
0000100 ^ 303 S 273 220 271 0 | 232 222 252 033 251 \r 372 g
0000110 n 221 177 ) 270 l \v X 315 w , ( \t 254 * $
0000120 023 031 ! | 003 J 0 262 002 030 230 321 4
0000130 340 233 216 337 360 261 \ ] 216 016 020 206 001 357 346 332
0000140 337 z 306 363 374 ] 354 323 335 [ 337 214 z 330 226 027
0000150 j 255 037 260 ' 027 356 333 F W V 200 030 H ; 337
0000160 \n 245 q 7 372 360 I 263 ; 326 316 321 306 030 q K
0000170 337 264 030 1 345 z 032 @ 357 301 ] 302 U < 037 262
0000180 363 272 241 231 346 s \0 337 216 235 375 236 [ 037 215 037
0000190 274 341 033 200 \0 \0 \0 \0 u 216 336 U 336 r 1 u
00001a0 \0 001 311 002 227 \n \0 \0 \n 224 r 242 261 304 g 373
00001b0 002 \0 \0 \0 \0 004 Y Z 375 7 z X Z \0 \0 004
00001c0 346 326 264 F 002 \0 ! 001 \b \0 \0 \0 330 017 # 023
00001d0 001 \0 \r # # # # W o r l d # # # #
00001e0 \n \0 \0 \0 x 360 \v ) 314 g 337 330 \0 001 & 016
00001f0 \b 033 340 004 037 266 363 } 001 \0 \0 \0 \0 004 Y Z
0000200
```
> Copilot:
> The hexdump you've provided appears to be a binary file. It's difficult to determine if it's a cause for concern just by looking at the hexdump. Here are a few things you could consider:
> 1. *File Origin*: If this file was added by a trusted team member and it's expected to be part of your code repository, it's probably safe. If the file's origin is unknown or it was added unexpectedly, you might want to investigate further.
> 2. *File Purpose*: Understanding what this file is used for can help determine if it's a cause for concern. If it's a binary used for testing or a necessary part of your application, it might be fine. If its purpose is unclear, it's worth checking.
> 3. *File Analysis*: You could use file analysis tools to examine the binary file. This could provide information about what the file does, which can help you decide if it's a cause for concern.
> 4. *Security Scans*: Consider running security scans on the file. There are many tools available that can scan binary files for known security vulnerabilities.
> 5. *Code Review*: If this file was added as part of a commit, make sure the commit was reviewed thoroughly. Unexpected binary files can sometimes be a sign of an insecure direct object reference (IDOR) vulnerability.
> Remember, when in doubt, it's always better to err on the side of caution. If you're unsure, consider reaching out to a security professional. They can help you analyze the file and determine if it poses any risk.
Lol.
---
> 2. Stop accepting shit tools like M4 and C for creating any software.
> You can never make the work of black hats impossible but you can trivially make it a whole lot harder.
What could be more trivially done than simply replacing C for all code?
---
> You:
> Below is a hexdump of a test file added to our code repository. Is it any cause for concern?
> Copilot:> The hexdump you've provided appears to be a binary file. It's difficult to determine if it's a cause for concern just by looking at the hexdump. Here are a few things you could consider:
> 1. *File Origin*: If this file was added by a trusted team member and it's expected to be part of your code repository, it's probably safe. If the file's origin is unknown or it was added unexpectedly, you might want to investigate further.
> 2. *File Purpose*: Understanding what this file is used for can help determine if it's a cause for concern. If it's a binary used for testing or a necessary part of your application, it might be fine. If its purpose is unclear, it's worth checking.
> 3. *File Analysis*: You could use file analysis tools to examine the binary file. This could provide information about what the file does, which can help you decide if it's a cause for concern.
> 4. *Security Scans*: Consider running security scans on the file. There are many tools available that can scan binary files for known security vulnerabilities.
> 5. *Code Review*: If this file was added as part of a commit, make sure the commit was reviewed thoroughly. Unexpected binary files can sometimes be a sign of an insecure direct object reference (IDOR) vulnerability.
> Remember, when in doubt, it's always better to err on the side of caution. If you're unsure, consider reaching out to a security professional. They can help you analyze the file and determine if it poses any risk.
Lol.
---
> 2. Stop accepting shit tools like M4 and C for creating any software.
> You can never make the work of black hats impossible but you can trivially make it a whole lot harder.
What could be more trivially done than simply replacing C for all code?