Re: Meltdown, aka "Dear Intel, you suck"
> We have received *no* non-public information. I've seen posts elsewhere by > other *BSD people implying that they receive little or no prior warning, so > I have no reason to believe this was specific to OpenBSD and/or our > philosophy. Personally, I do find itamusing? that public announcements > were moved up after the issue was deduced from development discussions and > commits to a different open source OS project. Aren't we all glad that > this was under embargo and strongly believe in the future value of > embargoes? if only the millionares and billionares benefit from receiving information to make improvements to the so-called open and free software stack, then the ecosystem has truly grown up to become captured and will soon gain all the market benefits of other supply chains -- such as ensuring you have inexpensive salmonella spinach on your table from purchased from a smallselection of vendors. But not safety, security, diversity, and choice. Some people should be ashamed of themselves, but they probably purchased options.
Re: /etc/services: two missing ports
> On Fri, Jan 05, 2018 at 08:17:42PM -0700, Theo de Raadt wrote: > > We've been avoiding polluting services with absolutely every joke > > of a service. If we added everything, it would be a disaster that > > we have to manage and we don't want to. > > > > Ok, no problem, yet asking again, now with some maintenance included. > > > You've hit on one of the two services we've watched over the years > > as markers between "registered" and "not registered". > > > > Then how about under unofficials? Sigh. It is like you didn't read what I wrote. We could make this file 4000 lines tomorrow. And find a couple of people to maintain the shitshow. But we elect not to do that.
Meltdown, aka "Dear Intel, you suck"
So, yes, we the OpenBSD developers are not totally asleep and a handful of us are working out how to deal with Intel's fuck-up aka the Meltdown attack. While we have the advantage of less complexity in this area (e.g., no 32bit-on-64bit compat), there's still a pile of details to work through about what has to be *always* in the page tables vs what can/should/must be hidden. Do KARL or other features of OpenBSD mitigate this? Not particularly. If you're running code from multiple trust domains then yeah, you're largely at risk. We have received *no* non-public information. I've seen posts elsewhere by other *BSD people implying that they receive little or no prior warning, so I have no reason to believe this was specific to OpenBSD and/or our philosophy. Personally, I do find itamusing? that public announcements were moved up after the issue was deduced from development discussions and commits to a different open source OS project. Aren't we all glad that this was under embargo and strongly believe in the future value of embargoes? Unless something unexpected happens, we'll be applying the workaround to amd64 first and then working out what to do for i386 and arm* (if still though to be necessary for arm) after that. No promises on only applying it to Intel CPUs or knobs to disable it, yet: we'll see how complex that would make things. As always, our own developer laptops are the first targets, so we're invested in it working and being usable. Philip Guenther guent...@openbsd.org
Re: /etc/services: two missing ports
On Fri, Jan 05, 2018 at 08:17:42PM -0700, Theo de Raadt wrote: > We've been avoiding polluting services with absolutely every joke > of a service. If we added everything, it would be a disaster that > we have to manage and we don't want to. > Ok, no problem, yet asking again, now with some maintenance included. > You've hit on one of the two services we've watched over the years > as markers between "registered" and "not registered". > Then how about under unofficials? > Have you found an application which does not know to use this > unregistered? > No, just netstat. > As for what netstat reports, you big boys can handle that being > just a number. That's why it prints numbers instead of blank space. > > been over 20years since i first connected to irc, and it was on 6667. i never knew about port 194, but am very sure it will never listen on udp. so i think those two should go, even if latter won't get in. slightly tested diff below; no vax was punished by the growth of services. -Artturi diff --git a/etc/services b/etc/services index ceb2b58c17d..172db3609f3 100644 --- a/etc/services +++ b/etc/services @@ -103,8 +103,6 @@ bgp 179/tcp # Border Gateway Proto. bgp179/udp prospero 191/tcp # Cliff Neuman's Prospero prospero 191/udp -irc194/tcp # Internet Relay Chat -irc194/udp smux 199/tcp # SNMP Unix Multiplexer smux 199/udp at-rtmp201/tcp # AppleTalk routing @@ -321,6 +319,8 @@ webster 2627/tcp# Network dictionary conserver 3109/tcp# console server canna 5680/tcp# Kana->Kanji server sane-port 6566/tcp# SANE Control Port +irc6667/tcp# Internet Relay Chat +irc6697/tcp# IRC over SSL icb7326/tcp# Internet Citizen's Band spamd 8025/tcp# spamd(8) spamd-sync 8025/udp# spamd(8) synchronisation
Re: /etc/services: two missing ports
We've been avoiding polluting services with absolutely every joke of a service. If we added everything, it would be a disaster that we have to manage and we don't want to. You've hit on one of the two services we've watched over the years as markers between "registered" and "not registered". Have you found an application which does not know to use this unregistered? As for what netstat reports, you big boys can handle that being just a number. That's why it prints numbers instead of blank space. > i don't know if anyone uses 6667 anymore, but adding it anyway > so the abbreviated one below w/" over SSL" does make more sense. > usually for me 6697 is the only port unrecognized by services(5) > in netstat output under Foreign Address, so this is for consistency, > and i believe these are official. > > -Artturi > > > diff --git a/etc/services b/etc/services > index ceb2b58c17d..146876ce065 100644 > --- a/etc/services > +++ b/etc/services > @@ -262,6 +262,8 @@ postgresql5432/tcp# > PostgreSQL > postgresql 5432/udp# PostgreSQL > rfb 5900/tcpvnc # Remote Framebuffer > syslog-tls 6514/tcp# syslog over TLS > +irc 6667/tcp# Internet Relay Chat > +irc 6697/tcp# IRC over SSL > afs3-fileserver 7000/tcp# AFS fileserver > afs3-fileserver 7000/udp# AFS fileserver > afs3-callback7001/tcp# AFS callback server >
/etc/services: two missing ports
Hi, i don't know if anyone uses 6667 anymore, but adding it anyway so the abbreviated one below w/" over SSL" does make more sense. usually for me 6697 is the only port unrecognized by services(5) in netstat output under Foreign Address, so this is for consistency, and i believe these are official. -Artturi diff --git a/etc/services b/etc/services index ceb2b58c17d..146876ce065 100644 --- a/etc/services +++ b/etc/services @@ -262,6 +262,8 @@ postgresql 5432/tcp# PostgreSQL postgresql 5432/udp# PostgreSQL rfb5900/tcpvnc # Remote Framebuffer syslog-tls 6514/tcp# syslog over TLS +irc6667/tcp# Internet Relay Chat +irc6697/tcp# IRC over SSL afs3-fileserver7000/tcp# AFS fileserver afs3-fileserver7000/udp# AFS fileserver afs3-callback 7001/tcp# AFS callback server
Re: mess with regression tests
On 23:36 Wed 13 Dec , Alexander Bluhm wrote:
> On Wed, Dec 06, 2017 at 11:19:18PM +0300, Sergey Bronnikov wrote:
> > Patch below adds similar scripts for ed, perl, gdb, libkeynote, ctags,
> > m4 and sed. Patch looks huge but it is actually simple. Anyway if you
> > want splitted patch I will resend.
>
> It is not the patch that is too big but the task. Try to start
> with one test, get it integrated, learn, and then do the next.
>
> I have only looked at ed as it is the first in your list.
>
> It generates a lot of errors:
> *** The script =.red exited abnormally ***
> *** The script a1.red exited abnormally ***
> *** The script i1.red exited abnormally ***
> *** The script i3.red exited abnormally ***
> *** The script k1.red exited abnormally ***
> *** The script nl.red exited abnormally ***
> *** The script r1.red exited abnormally ***
> *** The script s2.red exited abnormally ***
> *** The script =.red exited abnormally ***
> *** The script a1.red exited abnormally ***
> *** The script i1.red exited abnormally ***
> *** The script i3.red exited abnormally ***
> *** The script k1.red exited abnormally ***
> *** The script nl.red exited abnormally ***
> *** The script r1.red exited abnormally ***
> *** The script s2.red exited abnormally ***
>
> I think they have to be fixed, before I will run them. Importing
> failing tests is not a good idea.
>
> Although the tests fail, the regress framework does not recognize
> it. Running tests and not caring about the result is pointless.
>
> Then it creates temparary files in /usr/src/bin/ed/test. Ideally
> they should be in /usr/src/regress/bin/ed/obj and removed by make
> clean. If this is too complicated, we could leave it as it is.
> But we should at least try it.
>
> So please select one regress to start with, make it nicely pass and
> fail, fix the bugs and get your work commited. I will help you
> there.
>
> bluhm
I have updated patch for bin/ed and now the most part of tests are
works.
Tests =-err.ed, a1-err.ed, i1-err.ed, k1-err.ed and r1-err.ed
marked as skipped targets because README describe them as known failed.
Tests i3.red, nl.red and s2.red still fails and require some attention.
Patch requires some actions:
- rename =.err to something else, for example eq.err,
otherwise make will fail
- create regress/bin/ed/obj directory for a temporary files
I hardcoded an absolute path to the test dir in a makescripts target.
I don't know why but this doesn't work with $TESTDIR.
Sergey
diff --git a/bin/ed/test/=.err b/bin/ed/test/eq.err
similarity index 100%
rename from bin/ed/test/=.err
rename to bin/ed/test/eq.err
diff --git a/bin/ed/test/mkscripts.sh b/bin/ed/test/mkscripts.sh
index 2bf9b213235..ef8299770c7 100644
--- a/bin/ed/test/mkscripts.sh
+++ b/bin/ed/test/mkscripts.sh
@@ -6,6 +6,8 @@
PATH="/bin:/usr/bin:/usr/local/bin/:."
ED=$1
+OBJ=$2
+TESTS=$3
[ ! -x $ED ] && { echo "$ED: cannot execute"; exit 1; }
for i in *.t; do
@@ -31,13 +33,13 @@ for i in *.t; do
#!/bin/sh -
$ED - <<\EOT
H
- r $base.d
+ r $TESTS/$base.d
w $base.o
EOT
.
-2r $i
- w $base.ed
- !chmod +x $base.ed
+ w $OBJ/$base.ed
+ !chmod +x $OBJ/$base.ed
EOF
done
@@ -65,12 +67,12 @@ for i in *.err; do
#!/bin/sh -
$ED - <<\EOT
H
- r $base.err
+ r $TESTS/$base.err
w $base.o
EOT
.
-2r $i
- w ${base}.red
- !chmod +x ${base}.red
+ w $OBJ/${base}.red
+ !chmod +x $OBJ/${base}.red
EOF
done
diff --git a/regress/bin/ed/Makefile b/regress/bin/ed/Makefile
new file mode 100644
index 000..f54039e6065
--- /dev/null
+++ b/regress/bin/ed/Makefile
@@ -0,0 +1,31 @@
+# $OpenBSD $
+
+TESTDIR= ${.CURDIR}/../../../bin/ed/test/
+OBJDIR= ${.CURDIR}/obj
+ED= /bin/ed
+SHELL= /bin/sh
+CLEANFILES+= ${OBJDIR}/*.red ${OBJDIR}/*.ed ${OBJDIR}/*.o
+
+ARGS!= cd ${OBJDIR} && ls *.{ed,red}
+TARGETS?= ${ARGS}
+REGRESS_TARGETS= ${TARGETS:S/^/run-regress-/}
+REGRESS_SKIP_TARGETS+= run-regress-eq.ed \
+ run-regress-a1.ed \
+ run-regress-i1.ed \
+ run-regress-k1.ed \
+ run-regress-r1.ed
+
+regress: makescripts
+.for a in ${ARGS}
+run-regress-$a: $a
+ @echo '\n $a '
+ @${SHELL} ${.CURDIR}/ckscripts.sh ${ED} ${OBJDIR} ${TESTDIR} $a
+.endfor
+
+makescripts:
+ @cd ${TESTDIR} && $(SHELL) mkscripts.sh ${ED} ${OBJDIR}
"/usr/src/bin/ed/test"
+ @cp ${TESTDIR}/e1.t ${TESTDIR}/u.t ${TESTDIR}/r3.t ${OBJDIR}
+
+.PHONY: ${REGRESS_TARGETS}
+
+.include
diff --git a/regress/bin/ed/ckscripts.sh b/regress/bin/
Re: ksh: Fix compilation without job control
On Fri, 05 Jan 2018 16:15:45 +0100, Jeremie Courreges-Anglas wrote: > Cool, here's the diff. unifdef gives me the same result on jobs.c, > except for the indentation change in two conditionals. ok? OK millert@ - todd
Re: ksh: Fix compilation without job control
On Fri, Jan 05, 2018 at 04:15:45PM +0100, Jeremie Courreges-Anglas wrote: > On Fri, Jan 05 2018, "Theo de Raadt" wrote: > >> On Fri, 05 Jan 2018 08:20:03 +0100, Jeremie Courreges-Anglas wrote: > >> > >> > I kinda take job control in my shell for granted. Todd, would it make > >> > sense to just delete the #ifdefs? I doubt that we'll want to ship a ksh > >> > with no job control in space-constrained installers. > >> > >> I don't see any reason to support building ksh without job control. > >> I'd rather just delete the #ifdefs. > > > > Yep. > > Cool, here's the diff. unifdef gives me the same result on jobs.c, > except for the indentation change in two conditionals. ok? I was about to send the exact same diff, thanks :)
Re: ksh: Fix compilation without job control
On Fri, Jan 05 2018, "Theo de Raadt" wrote:
>> On Fri, 05 Jan 2018 08:20:03 +0100, Jeremie Courreges-Anglas wrote:
>>
>> > I kinda take job control in my shell for granted. Todd, would it make
>> > sense to just delete the #ifdefs? I doubt that we'll want to ship a ksh
>> > with no job control in space-constrained installers.
>>
>> I don't see any reason to support building ksh without job control.
>> I'd rather just delete the #ifdefs.
>
> Yep.
Cool, here's the diff. unifdef gives me the same result on jobs.c,
except for the indentation change in two conditionals. ok?
Index: c_ksh.c
===
RCS file: /d/cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.54
diff -u -p -r1.54 c_ksh.c
--- c_ksh.c 4 Jan 2018 19:06:16 - 1.54
+++ c_ksh.c 5 Jan 2018 15:07:03 -
@@ -1068,7 +1068,6 @@ c_jobs(char **wp)
return rv;
}
-#ifdef JOBS
int
c_fgbg(char **wp)
{
@@ -1092,7 +1091,6 @@ c_fgbg(char **wp)
*/
return (bg || Flag(FPOSIX)) ? 0 : rv;
}
-#endif
struct kill_info {
int num_width;
@@ -1398,10 +1396,8 @@ const struct builtin kshbuiltins [] = {
{"=typeset", c_typeset},
{"+unalias", c_unalias},
{"whence", c_whence},
-#ifdef JOBS
{"+bg", c_fgbg},
{"+fg", c_fgbg},
-#endif
#ifdef EMACS
{"bind", c_bind},
#endif
Index: config.h
===
RCS file: /d/cvs/src/bin/ksh/config.h,v
retrieving revision 1.16
diff -u -p -r1.16 config.h
--- config.h1 Aug 2017 14:30:05 - 1.16
+++ config.h5 Jan 2018 15:07:03 -
@@ -11,9 +11,6 @@
#ifndef CONFIG_H
#define CONFIG_H
-/* Include job control? */
-#define JOBS 1
-
/* Include brace-expansion? */
#define BRACE_EXPAND 1
Index: jobs.c
===
RCS file: /d/cvs/src/bin/ksh/jobs.c,v
retrieving revision 1.55
diff -u -p -r1.55 jobs.c
--- jobs.c 17 Mar 2016 23:33:23 - 1.55
+++ jobs.c 5 Jan 2018 15:07:03 -
@@ -86,10 +86,8 @@ struct job {
Proc*proc_list; /* process list */
Proc*last_proc; /* last process in list */
Coproc_id coproc_id;/* 0 or id of coprocess output pipe */
-#ifdef JOBS
struct termios ttystate;/* saved tty state for stopped jobs */
pid_t saved_ttypgrp; /* saved tty process group for stopped jobs */
-#endif /* JOBS */
};
/* Flags for j_waitj() */
@@ -127,13 +125,11 @@ static intchild_max; /* CHILD_MAX */
/* held_sigchld is set if sigchld occurs before a job is completely started */
static volatile sig_atomic_t held_sigchld;
-#ifdef JOBS
static struct shf *shl_j;
static int ttypgrp_ok; /* set if can use tty pgrps */
static pid_t restore_ttypgrp = -1;
static pid_t our_pgrp;
static int const tt_sigs[] = { SIGTSTP, SIGTTIN, SIGTTOU };
-#endif /* JOBS */
static voidj_set_async(Job *);
static voidj_startjob(Job *);
@@ -163,7 +159,6 @@ j_init(int mflagset)
setsig(&sigtraps[SIGCHLD], j_sigchld,
SS_RESTORE_ORIG|SS_FORCE|SS_SHTRAP);
-#ifdef JOBS
if (!mflagset && Flag(FTALKING))
Flag(FMONITOR) = 1;
@@ -189,10 +184,8 @@ j_init(int mflagset)
/* j_change() calls tty_init() */
if (Flag(FMONITOR))
j_change();
- else
-#endif /* JOBS */
- if (Flag(FTALKING))
- tty_init(true);
+ else if (Flag(FTALKING))
+ tty_init(true);
}
/* suspend the shell */
@@ -267,21 +260,18 @@ j_exit(void)
kill_job(j, SIGHUP);
else
killpg(j->pgrp, SIGHUP);
-#ifdef JOBS
if (j->state == PSTOPPED) {
if (j->pgrp == 0)
kill_job(j, SIGCONT);
else
killpg(j->pgrp, SIGCONT);
}
-#endif /* JOBS */
}
}
if (killed)
sleep(1);
j_notify();
-#ifdef JOBS
if (kshpid == procpid && restore_ttypgrp >= 0) {
/* Need to restore the tty pgrp to what it was when the
* shell started up, so that the process that started us
@@ -297,10 +287,8 @@ j_exit(void)
Flag(FMONITOR) = 0;
j_change();
}
-#endif /* JOBS */
}
-#ifdef JOBS
/* turn job control on or off according to Flag(FMONITOR) */
void
j_change(void)
@@ -389,7 +377,6 @@ j_change(void)
tty_close();
}
}
-#endif /* JOBS */
/* execute tree in child subprocess */
int
@@ -472,7 +459,6 @@ exchild(struct op *t, int flags, volatil
else
p->pid = i;
-#ifdef JOBS
/* job control set u
Re: ksh: Fix compilation without job control
> On Fri, 05 Jan 2018 08:20:03 +0100, Jeremie Courreges-Anglas wrote: > > > I kinda take job control in my shell for granted. Todd, would it make > > sense to just delete the #ifdefs? I doubt that we'll want to ship a ksh > > with no job control in space-constrained installers. > > I don't see any reason to support building ksh without job control. > I'd rather just delete the #ifdefs. Yep.
Re: ksh: Fix compilation without job control
On Fri, 05 Jan 2018 08:20:03 +0100, Jeremie Courreges-Anglas wrote: > I kinda take job control in my shell for granted. Todd, would it make > sense to just delete the #ifdefs? I doubt that we'll want to ship a ksh > with no job control in space-constrained installers. I don't see any reason to support building ksh without job control. I'd rather just delete the #ifdefs. - todd
Re: ksh: Typofixes
fixed, thanks
ksh: Typofixes
diff --git a/bin/ksh/jobs.c b/bin/ksh/jobs.c
index 0623f4c6171..c368e4e5f71 100644
--- a/bin/ksh/jobs.c
+++ b/bin/ksh/jobs.c
@@ -67,7 +67,7 @@ struct proc {
#define JF_CHANGED 0x040 /* process has changed state */
#define JF_KNOWN 0x080 /* $! referenced */
#define JF_ZOMBIE 0x100 /* known, unwaited process */
-#define JF_REMOVE 0x200 /* flagged for removal (j_jobs()/j_noityf()) */
+#define JF_REMOVE 0x200 /* flagged for removal (j_jobs()/j_notify()) */
#define JF_USETTYMODE 0x400 /* tty mode saved if process exits normally */
#define JF_SAVEDTTYPGRP0x800 /* j->saved_ttypgrp is valid */
@@ -1341,7 +1341,7 @@ j_print(Job *j, int how, struct shf *shf)
int output = 0;
if (how == JP_PGRP) {
- /* POSIX doesn't say what to do it there is no process
+ /* POSIX doesn't say what to do if there is no process
* group leader (ie, !FMONITOR). We arbitrarily return
* last pid (which is what $! returns).
*/
Re: VMD: revise check for regular files on disks
Jeremie Courreges-Anglas wrote:
> On Wed, Jan 03 2018, Carlos Cardenas wrote:
> > Howdy.
> >
> > Attached is a patch to address a TOCTOU issue with checking to
> > ensure disks are regular files, reported by jca@ .
> >
> > Comments? Ok?
>
> A bit late, but ok.
>
> While here, if the S_ISREG check fails there is no meaningful errno to
> report.
>
> ok?
>
ok ccardenas
>
> Index: config.c
> ===
> RCS file: /d/cvs/src/usr.sbin/vmd/config.c,v
> retrieving revision 1.39
> diff -u -p -p -u -r1.39 config.c
> --- config.c 4 Jan 2018 15:19:56 - 1.39
> +++ config.c 5 Jan 2018 07:24:41 -
> @@ -252,7 +252,7 @@ config_setvm(struct privsep *ps, struct
> goto fail;
> }
> if (S_ISREG(stat_buf.st_mode) == 0) {
> - log_warn("%s: cdrom %s is not a regular file", __func__,
> + log_warnx("%s: cdrom %s is not a regular file",
> __func__,
> vcp->vcp_cdrom);
> errno = VMD_CDROM_INVALID;
> goto fail;
> @@ -276,7 +276,7 @@ config_setvm(struct privsep *ps, struct
> goto fail;
> }
> if (S_ISREG(stat_buf.st_mode) == 0) {
> - log_warn("%s: disk %s is not a regular file", __func__,
> + log_warnx("%s: disk %s is not a regular file", __func__,
> vcp->vcp_disks[i]);
> errno = VMD_DISK_INVALID;
> goto fail;
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: update Mesa to 17.2.6
Hi, On Fri, Jan 05 2018 10:09:08 +1100, Jonathan Gray wrote: > Does switching to the intel driver with xorg.conf or the below > diff change anything? Yes, with the intel driver the corruption is gone. However, I updated my work Haswell laptop (x240; cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.72 MHz; inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x0b) and it does exhibit similar corruption; it's more difficult to notice as it seems to clear away faster but it's there, at least if you know to look for it (I can provide a shaky-cam video if you like). It too goes away when switching to intel driver, so perhaps your diff isn't quite sufficient (although granted, with Haswell the effect is so much less noticeable, it may not be a problem). -- Lauri Tirkkonen | lotheac @ IRCnet
Re: VMD: revise check for regular files on disks
On Fri, Jan 05, 2018 at 08:26:21AM +0100, Jeremie Courreges-Anglas wrote:
> On Wed, Jan 03 2018, Carlos Cardenas wrote:
> > Howdy.
> >
> > Attached is a patch to address a TOCTOU issue with checking to
> > ensure disks are regular files, reported by jca@ .
> >
> > Comments? Ok?
>
> A bit late, but ok.
>
> While here, if the S_ISREG check fails there is no meaningful errno to
> report.
>
> ok?
>
ok mlarkin
>
> Index: config.c
> ===
> RCS file: /d/cvs/src/usr.sbin/vmd/config.c,v
> retrieving revision 1.39
> diff -u -p -p -u -r1.39 config.c
> --- config.c 4 Jan 2018 15:19:56 - 1.39
> +++ config.c 5 Jan 2018 07:24:41 -
> @@ -252,7 +252,7 @@ config_setvm(struct privsep *ps, struct
> goto fail;
> }
> if (S_ISREG(stat_buf.st_mode) == 0) {
> - log_warn("%s: cdrom %s is not a regular file", __func__,
> + log_warnx("%s: cdrom %s is not a regular file",
> __func__,
> vcp->vcp_cdrom);
> errno = VMD_CDROM_INVALID;
> goto fail;
> @@ -276,7 +276,7 @@ config_setvm(struct privsep *ps, struct
> goto fail;
> }
> if (S_ISREG(stat_buf.st_mode) == 0) {
> - log_warn("%s: disk %s is not a regular file", __func__,
> + log_warnx("%s: disk %s is not a regular file", __func__,
> vcp->vcp_disks[i]);
> errno = VMD_DISK_INVALID;
> goto fail;
>
> --
> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
