Hacker Newsnew | past | comments | ask | show | jobs | submit | zalmoxes's commentslogin

I'm neither an employee nor a customer, just someone who was following the project on twitter because it looked very intriguing. I just want to say that the comments on this thread are absolutely ridiculous and I expected better. Does anyone actually think the customers would find out at the last minute? That the company would leave its users without any support? It's baseless speculation and my guess is it's totally wrong. - The company is founded by Blake Mizerany https://twitter.com/bmizerany?lang=en an engineer known for Sinatra and a bunch of other well respected projects. - The users adopting an early stage startup's product are likely friends/former colleagues who are putting personal trust into the team. Does anyone really think nobody got a heads up, or possible support deals while they migrate?

Second, Backplane really looked like great tech https://www.youtube.com/watch?v=43wFJBRTHG0


The customers did find out at the last minute. Weeks notice is last minute.


I think zalmoxes' point was that they may have found out through direct contact from the founders, or a customer-only email 2 weeks ago - rather than just by loading up the homepage today.


> Weeks notice is last minute.

Well, no, it's literally not. It's actually a reasonably long lead time for “going out of business”, which basically no one ever announces before essentially all hope of finding a way to keep the business running is exhausted, which intrinsically means there is little runway left.


Yep, it literally is last minute for a platform product used by others during a time of the year when the developers responsible for finding/building a replacement would otherwise have gone on vacation.

If this were a tangible product, a week notice would be fine since it gives customers time to stock up.


> Does anyone actually think the customers would find out at the last minute?

Two weeks notice at a time where people frequently take vacation time is very much "last minute".

> That the company would leave its users without any support?

"It's all gonna stop working on December 29th" does seem to do exactly that.


> I just want to say that the comments on this thread are absolutely ridiculous and I expected better. Does anyone actually think the customers would find out at the last minute? That the company would leave its users without any support? It's baseless speculation and my guess is it's totally wrong.

Well, it's their baseless speculation and your guess, so a level playing field. You can make the same point without baiting other commenters—in fact you just make your point without baiting other commenters, that's how.


It sounds exactly like customers got last minute notice right before the holidays when everything shuts down.

Of all the times they could have chosen to shut down, they chose the absolute worst.

If I still programmed, I would never use this guy's products ever again.


Hi, I'm the author(along with several other developers). MicroMDM is used in some enterprise environments and was recently mentioned in a number of security presentations regarding Apple's MDM and Device Enrollment Program services.

https://duo.com/labs/research/mdm-me-maybe https://i.blackhat.com/us-18/Thu-August-9/us-18-Endahl-A-Dee...


Do you know if a small business can use DEP features?

Could per-app VPNs be used without DEP? If so, could they be used with MicroMDM, native iOS IPSEC client and an open-source VPN server, or is a 3rd-party VPN client like Cisco required for per-app VPN?


Anyone can use DEP, just need a DUNS number to enroll into the program, and then to purchase devices from apple direct, or from an approved reseller. Unfortunately you cannot retroactively add devices that were already purchased.

DEP is not required for the VPN profile configs, that can be applied with just MDM (or even manually). The VPN payloads are documented here https://developer.apple.com/enterprise/documentation/Configu...


Speaking as a former Apple employee I can say with 100 percent certainty that you can add devices post purchase even before DEP existed. There are a number of ways:

If the device was purchased on or after March 1st 2011 you can do the following:

1. Work with your reseller if they participate in DEP to get the devices enrolled retroactively. Sometimes you have to put the nails on the reseller (they can pretty bad about this. Looking at you Verizon) but it absolutely can be done.

2. If your devices are eligible and were a direct purchase from Apple you should contact Apples enterprise support and they can start the process of double checking eligibility and getting those devices enrolled accordingly. This is pretty straightforward.

3. You can enroll eligible devices via Apple Configurator 2 into DEP using the process described here:

https://help.apple.com/configurator/mac/#/cad99bc2a859

Using Apple Configuratior 2 will allow you to bypass any reseller to enroll into DEP so it’s your best move if you are having issues getting people to do it fast enough. Any eligible device can be enrolled this way

Here’s a relevant help link with phone numbers more On eligibility and enrolling etc

https://support.apple.com/en-us/HT204142#manual

I see this misinformation so much so please help share it if you can


You can add iOS devices to DEP if they were not purchased when you had your business account set up using Apple Configurator.

https://support.jamfnow.com/hc/en-us/articles/360000004483-U...


> purchase devices from apple direct, or from an approved reseller. Unfortunately you cannot retroactively add devices that were already purchased.

So you need to provide a DEP-authorized account number to the salesperson in an Apple store? Is this possible when buying online from apple.com?

Any idea why Apple does not provide a service to test whether a device serial number is DEP-managed? It would deter attempts to resell DEP-managed devices.


You must buy your devices through the enterprise store, and then it is automatically linked to DEP.

Any idea why Apple does not provide a service to test whether a device serial number is DEP-managed?

Because once you know the serial number of a DEP device you can enroll into the MDM. There is virtually no security. See https://duo.com/labs/research/mdm-me-maybe


There is reasonable security. From your link:

> an attacker that obtains such a serial number ... will be able to enroll a device of their own as if it were owned by the organization, as long as it's not currently enrolled in the MDM server.

So, the rule is at-most-once enrollment.

And further down:

> some organizations elect not to require user authentication as part of MDM enrollment.

IOW, if you are not enabling authentication, you have only yourself to blame.


Thanks for the pointer, some good reasons there to avoid DEP.


Are those the same profiles generated by Apple Configurator 2? I was able to get per-site Safari VPNs added by manually editing XML in the profile, but no success with per-application VPNs.

Commercial MDM providers only whitelist a handful of VPN client apps for per-app VPN profiles. Why are those needed when there is already a native iOS VPN client for IPSEC?


Funnily enough I have been trying to do that today - I don't think you can. You create the per app VPN with a UUID, but the only way to associate an app to a Per-App-VPN definition is through MDM - I think.


The next question would be whether it requires DEP, or could be done with open-source MicroMDM or the $20 macOS Server app.


they should be the same, yes. You can compare the .mobileconfig file with the spec from the PDF.

That's all commercial vendors do, push these XML files to your device.


You can retroactively add devices as of iOS 11 they have enabled it through Apple Configurator on any Mac device.


I’m one of the security researchers that zalmoxes linked above (the Black Hat talk) =)

Duo very nicely gave multiple shout outs in their post. Including to zalmoxes (above), as well as my co-presenter and I. Sadly the traditional vendors in the space don’t have a track record of caring about security engineering. I’m glad that Duo’s latest research emphasizes the importance of authenticating the device enrollment process in particular. We touched on this in our whitepaper^, but it wasn’t a primary focus of our research and we didn’t tie it back to the shortcomings of DEP’s lack of verification around device identity. Extremely happy to see more focus on this stuff.

^See the vendor security checklist section of our whitepaper. Specifically, the bit about using an HMAC within the SCEP payload.

Full transparency: I’m cofounder/CSO of a security focused product in the MDM space (fleetsmith.com).


The server is only meant for enterprise deployments. It would be pretty hard to do this on a personal level because you need to apply for an enterprise account with Apple, and request a very specific push certificate option.


You can't even sign up for the Enterprise program if your Apple ID is associated with the Apple Developer Program. You'll get the following error when signing up:

> Your Apple ID is already associated with a Team Agent enrolled in this program


You should contact developer relations they can get you hooked up with the same account


Setting up Mobile Device Management itself is not particularly onerous, it's definitely best practice to create a new Apple ID for that purpose, however. A technical individual can already do this easily enough with the freely-available Meraki MDM. The Device Enrollment Program I believe is more complicated and inaccessible to individuals (haven't dealt with this personally), and is quickly becoming a prerequisite for many of the more invasive and useful capabilities, like the kext signing and deployment mentioned on the MicroMDM homepage.


Meraki MDM is not free anymore AFAIK. But if you signed up while they offered the 100 free devices plan it's still valid.


Hm, guess I missed that...and their offering has a long way to go before I'd consider it worth paying for. An alternative then might be Jamf, they recently started offering a free tier with a handful of devices for their hosted 'Jamf Now' MDM (or at least it's free via their promotions on sites like Daring Fireball).


Anyone can get a push certificate, it's not just businesses,

https://identity.apple.com/pushcert/


MDM push notifications require to be signed by a special certificate, which is only available upon request.


While that is true, anyone can get a push notification cert, this is a different cert..


At [Kolide](https://kolide.com/) we're heavy users of Go Kit, and as a result have also adopted a lot of the style Peter recommends here. We've been slowly expanding on it with a style guide and company specific set of common libraries [here](https://github.com/kolide/kit#kolide-kit). My coworker also wrote a [blog post](https://blog.kolide.com/using-go-for-scalable-operating-syst...) on how Go has been fantastic for us and references the above style guide.

The code from go kit and [oklog](https://github.com/oklog/oklog) are great examples of idiomatic Go. Unfortunately the community at large doesn't really follow the "no init"/"no package global vars", which can sometimes lead to bad experiences importing opensource Go libs.


I feel like go-kit is quite antithetical to the Go mindset...it presents a lossy abstraction as a means of future-proofing against eventualities that will almost certainly never be encountered

to be honest it strikes me as the sort of library that excites intermediate developers who tend to over-architect


Your "almost certainly never" is another organization's "certainly inevitable" or "already happened". Go kit's scope and applicability is pretty clearly enumerated in the documentation. And there's nothing lossy about its abstractions.


I fully agree, unlike many others that are voting down this and other criticisms. The amount of boiler plate that go-kit adds is crazy.


I vouched for this comment - why would it deserve to be flagged?


This comment in particular wasn't flagged: 'junkscience2017 is banned. Note it was marked [dead], not [flagged].


Thanks for the explanation!


> the sort of library that excites intermediate developers

I find this true about nearly all microservices in Go. Microservices are much more useful in something like Node that can only take advantage of 1 OS thread per instance. Without containerization and load balancing in Node you wouldn't be able to scale.

Go on the other hand can efficiently utilize a nearly unlimited amount of threads as necessary with its scheduler. You're much more likely to over-architect if you don't keep this capacity in mind.


Opting-in to microservices has almost nothing to do with CPU efficiency.


RIP

I have a few services which were using Go’s acme/autocert package. I now need to update them to the HTTP challenge.


xenolf/lego arguably has the widest support in the sense of ACME verification methods, but autocert might get other methods too: https://github.com/golang/go/issues/21890


As a makefile pragmatist (they’re awful but easy to get started with/most know them) I’m debating between mage and Bazel.

I like mage because it would eliminate a lot of make and bash silliness, but I also want to get into Bazel because of all the things it promises.


Francesc Campoy’s Just for Func series is much better https://m.youtube.com/watch?t=420s&v=mTd3hHUy9OU

Also by a Google engineer and using Google Cloud products, but it’s actually a lot of fun to watch.


Thanks for this. I poked through his videos and I agree with your sentiment.


Yes that's true. But Docker did popularize it, at least that's how I initially read about it.

It's exciting to see that TUF is now a CNCF project.


We did use cobra in fleet, and worked hard not to use globals https://github.com/kolide/fleet/blob/f909f4808b17ffd5616c6c8...

It's doable, but it was hard and while cobra is a nice library, it's probably overkill unless you're a project like kubernetes.

Most projects in Go are very small in terms of configuration surface, and something like https://github.com/kolide/launcher/blob/9dcf149957b9e9757a24... is much cleaner IMO.


Yeah, I think I will try the simpler approach. I generally just have stuff like

  tool [-debug] [-store sqlite] cmd [-opt] [arg]
So, main needs to bootstraps logger and store and then delegate to downstream commands that almost always will consume the store and logger.

I'm currently using PersistentPreRunE to bootstrap the logging and store.. but I'm not really happy with the end result and some things are awkward. Maybe it would be less awkward if cobra had a 'Context' I could stick things in. The last issue was I added a version subcommand, which kept creating the store. I ended up having to do

  PersistentPreRunE:  func(cmd *cobra.Command, args []string) error { return nil },
  PersistentPostRunE: func(cmd *cobra.Command, args []string) error { return nil },
Which would have been a lot simpler if I was doing things manually.


If you haven't already, join the MacAdmins Slack. https://macadmins.herokuapp.com It's an open-invite slack team with over 12000 users - sysadmins, MDM developers, security researchers and so on.

We have various ongoing efforts to document and improve the macOS experience for users. If you have a macOS question, you'll likely find the answer there.


> you'll likely find the answer there

Well, I hope the Google Bot (plus whichever one DDG uses) also has an invite to that proprietary, closed, messaging system, or that the "macadmins" owner has set up a channel mirroring system ala IRC web logs, otherwise the system you described isn't contributing to the open body of knowledge.

Related, although mildly off topic, :fu: slack search


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: